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ON THE FRONT LINE OF GAME INNOVATION 




PLAN 




A Business Case for 
Publishing Source Code 



"This is your web site — it's Open Source — 
and I wont you to help us build it... Tal<e a 
lool< at our source code. Send us your ideas 
on how to improve it, and build a better 
campaign web site. The Gore 2000 
Volunteer Source Code Project wants to 
hear from you today!" 

—Vice President Al Gore, 
from his presidential campaign website 
littp://www.algore2ooo.com 

"I've heard reports of a number of compa- 
nies calling software 'open source' even 
though it does not fit the official definition. 
I've observed some instances myself " 

— Richard Stallman, 
from the GNU Project web server 

http://www.gnu.org 

At the Game Developers 
Conference in March, I got 
into a conversation with 
someone as to whether 
Open Source software could ever be 
commercially successful in our industry. 
WhilesomeOpen Source game projects 
already exist (such asCRYSTAL Space — 
see http://crystal.linuxgames.com for 
more information), wequickly came to 
the conci usion that the chances of an 
Open Source game becoming a commer- 
cial success a la Linux were slim to nil. 
That's not to say that projects like 
Crystal Space are fruitless — on the 
contrary, I can't think of a better route 
to learn about game technology and 
meet like-minded individualsthan by 
working on a Open Source project. It's 
just that an Open Source project carries 
with it certain baggage, like implied per- 
mission to modify and derive other 
works from the source code. In an 
industry that already gets pummel ed by 
critics for publishing too many copycat 
games, this reason alone makes it 
unlikely. That's just the beginning, too 
— there are a host of other reasons why 
a game company might not want to 
Introduce the world to its intellectual 
assets. It can be a scary proposition. 

All of this isn't to say that releasing 
sourcecode is necessarily foolish. For 
some companies, releasing large chunks 
of source code has helped to sell prod- 
uct, id, of course, is the obvious exam- 
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pleto point to. It's been releasing large 
amounts of its games' code to the public 
for years. I asked Brian Hook about the 
company's motivation for posting 
Doom , Quake and Quake 2 source to 
id's website. His response might shed 
some light on both why this company 
went ahead and posted their code and 
whether you ought to consider it also. 

Hook isquick to point out whiletheir 
recent games had some form of source 
code released with them, none of the 
graphics, networking or core client code 
was distributed. TheQuAKE gamelogic 
was based on QuakeC, and that was 
released. Quake 2 encapsulated its game 
logic in a .DLL, and that sourcecode 
was also released. In other words, the 
company surgically removed certain 
portionsof their games and posted that 
code. Furthermore, letting someone see 
your code does not imply permission to 
use it in another commercial game. 

There were some strong benefits that 
id felt made its decision to post the code 
worthwhile, and you might take these 
reasons into consideration if your team 
is mulling over the idea. The bottom 
line. Hook explained, was that it helped 
build their player community. Once 
players had access to specific sections of 
the code, people began writing mods, 
building new levels, designing new art- 
work for the game, and so on. That in 
turn extended the shelf life of the game 
and fostered communication within the 
Quake community. Hook also said that 
an unintended benefit was technical 
feedback: "Individuals with strong com- 
petency in afield that is not one of our 
strengthsmay be ableto offer adviceon 
a subject; and legitimate bugs can be 
found in our code by 'virgin' eyes." 

To release code or not to release — it's 
a big question. There are issues of addi- 
tional customer support, fear that your 
competition might learn something 
from your code that you'd rather not 
teach them, and so on. But the concept 
has merits that you shouldn't dismiss 
without investigating what you might 
gain. "Power to the people" might be 
your company's motto someday. ■ 
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New Products 



glAnalyze Dissects Games 

3D PIPELINE, a contract programming 
firm specializing in graphics software 
development, recently released 
glAnalyze, an instrumented OpenGL 
driver which provides real-time infor- 
mation about OpenGL applications. 
glAnalyze lets you peek inside 
OpenGL applications to better undert- 
stand how they work, on the premise 
that your analysis will help you build 
faster applications by studying the 
competition. 

As an OpenGL application runs, 
glAnalyze allows you to set breakpoints 
to stop rendering. Breakpoints can be 
set on end of frame, end of primitive, 
gl Error, on specific OpenGL API entry 
points, and so on. This feature is espe- 
cially useful for understanding individ- 
ual primitives and frames. At break, the 
user can review all thepriorAPI calls 
(including data) to see what led up to 
the current display. Breakpoints can also 
be invaluablefor tracking down unex- 
pected state changes or errant polygons. 

Here's a scenario where glAnalyze 
would come in handy. Say you've just 
bought a game similar to the one 




you're currently working on, and you 
want to see how it works. Without the 
source code, it could be tough. 
However, using glAnalyze to control 
and manage the game's OpenGL calls, 
you could determine the type of geom- 
etry that the game uses, count and 
classify primitives (triangles, quad- 
strips, and the like), gain insights as to 
how the developers optimized it, what 
types of state changes are going on, 
count textures, and so on. glAnalyze 
runs on Windows 95/98/ NT, and is 
priced at $295. 
■ 3D Pipeline Corporation 

La JoUa, Calif. 

(619) 551-5493 

http://www.3dpipeline.com/pr0ducts/ 
glAnalyze.htm 

EZ Environments in 3D 

METACREATIONS unveils Canoma. Over 
the years, various companies have 
come up with ways to turn a 2D draw- 
ing or photo into 3D geometry. The 
latest company to throw its hat in this 
ring is MetaCreations, and I'd say it's 
done a pretty nice job with its new 
product, Canoma. With Canoma, 
which runs on either the Windows or 
Macintosh platforms, you can easily 
take a photograph and turn the entire 
scene into some basic 3D geometry 
that you could stroll around in. 

Canoma imports photos, and using a 
beautiful KPT Bryce-like interface, you 
can start overlaying primitives onto 
objects in the scene. You can scale 
primitives so that they align well with 
objects in the photo, and you can add 
and subtract control points on the 
geometry when working with irregular- 
ly shaped items (like people). In other 
words, the product lets you apply 
geometry to textures, rather than the 
other way around. 

Once you have defined the primi- 
tives in the scene, you can move 
about in the scene and see objects 



New Products: glAnalyze from 3D 
Pipelind, Metacreations's Canoma, and 
a middleware physics engine from 
Math Engine, p. 9 



Industry Watch: Ultima players dis- 
cover eBay, Ms. Croft lands her first 
endorsement deal, Bleem bests Sony, 
and other serious news. p. 10 



Field Report: Ben Sawyer wraps up 
the first-ever Independent Games 
Festival, held during this year's GDC. 
pp. 12-13 

within the photo from different 
angles. Canoma takes care of correct- 
ing the perspective of textures. Of 
course, you'll have to take photos 
from different angles to capture back 
sides of object that a single photo- 
graph wouldn't reveal, but the appli- 
cation lets you stitch textures from 
different photos into the scene to 
make this feasible. Pricing for Canoma 
has not yet been revealed. 

■ MetaCreations 
Carpinteria, Calif. 
(805) 566-6200 

http://www.metacreations.com 

Middleware for Physics 

MATHENGINE. If the Trespasser 
Postmortem in this issue doesn't scare 
you away from the complicated world 
of realistic physical modeling in games 
(and hopefully it won't), a new product 
called Math Engine might bear some 
investigation. MathEngine is game 
"middleware" for handling object 
physics in real time. Like its name sug- 
gests, it's a number-cruncher that takes 
care of some of the hairy math code 
needed to model object interactions 
rapidly and in a way that looks realistic. 

MathEngine'sC language interface 
supports real-time articulated bodies, 
friction and a generalized collision han- 
dling system, and different surface 
material properties, plus a variety of 
other features. Though based in C, the 
company states that the SDK has "an 
object-oriented feel" that centers 
around a world object and body objects 
within that world. 

It requires Windows 95/98/NT, and 
is available as a free download from 
the MathEngine web site. Pricing for 
commercial products is $1, plus $.01 
royalty per game sold. 

■ MathEngine Inc. 
San Francisco, Calif. 
(415) 495-1738 
http://www.mathengine.com 



The Canoma interface for creating 
and exploring 3D environments. 



http://www.gdmag.com 



JUNE 1999 GAME DEVELOPER 



BIT BLASTS - INDUSTRY WATC 





Industry Watch 



ACCLAIM REPORTED ROSY RESULTS for 

its second fiscal quarter ending February 
28. The company's net revenues for that 
period were $135.7 million, an increase 
of 96 percent over the previous year. 
Net earnings for the quarter were $14.5 
million, compared with a net loss of 
$1.2 million for the same period a year 
earlier. Acclaim's second quarter was 
buoyed by a great holiday season 
thanks to the N64 titles Turok 2: Seeds 
Of Evil and South Park. 

SGI IDENTITY. Silicon Graphics, known 
the world over for years by its 
acronym, SGI, officially changed its 
name to SGI . According to the compa- 



UPCOMING EVENTS 

CALENDAR 



June 10-11, 1999 

PC Data's 1999 Trends 

TheW Hotel 
San Francisco, Calif. 
Cost: $295 to $495 
http://www.pcdata.com/ con- 
ferences 



June 26-27, 1999 

Develop! 99 

Olympia Conference Centre 
London, England 
Cost: early bird rates available 
h tt p :// www. u n mf . co m 



June 30-July Z, 1999 



MedPi '99 Software 

Congress Center and 
Auditorium of Monaco 
Monte Carlo, Monaco 
Cost: variable 

http://www.unmf.fr/an gl ai s/ 
salons-a.htm 




ny, "the corporate 
identity strategy was 
supported by the 
results of global 
branding consul- 
tants, Landor 
Associates." For its next act, Landor 
will unveil a new identity for the 
National Aeronautics and Space 
Administration.... 

BLEEM BESTS SONY. Sony's legal 
department is getting plenty of experi- 
ence as it jousts with various makers of 
Playstation emulators. Last time we 
caught up with Sony, they were 
wrestling with Connectix. This time, 
Sony's going after Bleem 
(http://www.bleem.com), a three-per- 
son company which manufactures a 
$25 PSX emulator for PCs. Once again, 
however, Sony was denied satisfaction 
in court: a San Francisco federal district 
court judge denied the company's 
request for a temporary restraining 
order, which would have stalled 
Bleem's product launch. 



HIGH STAKES FOR SEGA. The impor- 
tance of the U.S. launch of the 
Dreamcast is looking more and more 
like a make-or-break situation for Sega. 
Yasuo Tazoe, the corporate senior vice 
president at Sega Enterprises Ltd., esti- 
mated that the Japanese arcade market 
saw a 20 percent decline in the number 
of people playing arcade games from 
1997 to 1998 — probably due to the 
increased use of cellular phones and the 
Internet by kids, he said. Sega of Japan's 
arcade division has been the only robust 
element of the parent company for 
sometime, and to a large extent, it has 
helped float Sega of America over the 
past five years. If the arcade division 
continues to decline, a Dreamcast flop 
(i.e., insignificant sales in the next two 
years in the U.S. and Japan) could sink 
the company worldwide. 

EBAY AND ULTIMA. If you've ever 
scanned the auction lists on eBay, you 
know that everything has a price tag 
these days, even money — game cur- 



rency, that is. Yes, the Ultima Online 
player community is putting eBay to 
good use selling all sorts of intangible 
game items, from high-level characters 
to real estate in the game worlds to, 
most interestingly, game currency. 
PI ayers are sel I i n g th ei r i n -game n est 
eggs for U.S. dollars. TheUO currency 
market hasn't quite settled down yet 
(week-long auctions don't make opti- 
mal currency markets), so if you've ever 
considered a career in arbitrage, here's 
your chance to make your first million. 

BlMlif ^ 



Ultima Oline players bid for virtual 
money on eBay. 



CROFT LANDS FIRST ENDORSEMENT 
DEAL. For a while, everyone was talking 
about ad placement in games. Finally, 
I'm pleased to see that the worm has 
turned. Welcome to game placements 
in ads. Lara Croft is the television 
spokesmodel for an Australian energy 
drink called Lucozade. Eidos proves 
that digital superstars are the best kind, 
because polygonal models don't care 
who they pitch for or how it affects 
their career. 

GT INTERACTIVE HITS A ROUGH PATCH. 

The company said that it's going to lay 
off 35 percent of its staff, amounting to 
650 employees, and that it will take a 
one-time charge of $25-$30 million 
related to its recently announced cor- 
porate reorganization and relocation. 
GT is expecting a net loss in the fourth 
fiscal quarter to the tune of $50-$55 
million. 

WHIFF OF Y2K? If you thought that the 
Y2K hysteria was exactly that, and that 
games had nothing to fear from clock- 
related problems, here's a story to 
chew on. When Windows altered sys- 
tem clocks around the world this 
Spring to account for Daylight Savings 
Time, many players of Hasbro's 
RoLLERcoASTER TYCOON found that they 
could no longer play previously saved 
games. To remedy the situation, 
Hasbro had to issue a RCT time-zone 
utility to customers. ■ 
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Singularity Software won Best Overall Game and the Audience Award for Fire and 
Darkness. Thie grand prize was a cliecl< for $10,000. 



The First 
^Independent 
Games Festival: 
Recognition Without a 
Nillion-Dollar Budget 

bif Beit Safirtf er 

It was a moment of innocence, per- 
haps naivete, that demonstrated how 
new and exciting the first-ever 
Independent Games Festival was: as 
the development team from Vicarious 
Visions accepted their Best Audio 
award and began to leave the stage, 
they forgot to take their trophy with 
them. The event's emcee, Alex Dunne, 
tapped one of the departing develop- 
ers on the shoulder and reminded 
him. "Here, you're supposed to take 
this with you," Dunne said, handing 
the team its award. And who can 
blame these winners for not fully 
comprehending that their indepen- 
dently developed game. Terminus, had 
just garnered a metallic plaque and 
$1,000 check? They were too busy 
thanking whomever it is that game 
developers thank. 



So started the first Independent 
Games Festival (IGF), which was held 
M arch 17, at the Game Developers 
Conference in San Jose, Calif. The 
event grew out of an editorial that 
appeared in this magazine last 
September, and from its inception, the 
process of pulling together the IGF took 
everyone involved into uncharted terri- 
tory. Hollywood may not know much 
about developing games, but you have 
to admit that Tinseltown has got that 
awards thing down pretty well. 

The event began with an introduc- 
tion from GDC Director Jennifer 
Pahlka, who described the launch of 
the IGF as a "labor of love" for every- 
one involved in its production. 
Attendees piled into the awards area, a 
large crowd began to build, and the 15 
IGF finalists awaited to see what game 
would take home the evening's top 
award for Best Overall Game — worth 
$10,000 and publishing consideration 
by G.O.D. Games. To Pahlka's left on 
stage was an easel with one massively 
oversized check, with the requisite 
black drape hanging over it to conceal 
the winner's name. When Dunne came 
on stage and looked over at the check, 
he remarked, "I kind of feel like Ed 
McMahon tonight." 
A SUNDANCE INSPIRATION. How did the 
festival reach this point? Like many 
crazy ideas, it began over beers at a San 



Francisco bar. More than a year ago, a 
friend of Dunne's returned from the 
Sundance Film Festival, and after 
describing the event, this magazine's 
editor felt like it was natural event for 
the game industry to adopt. Months 
later, after sitting on the idea for a 
while, he wrote an editorial asking 
"Where's our Sundance?" (Game Plan, 
September 1998). The feedback from 
th e i n d ustry was en cou ragi n g ( wel I , 
nobody called Dunne crazy to his face 
at least), so preparations were made to 
launch the event at the GDC. By mid- 
October, with the help of its primary 
sponsor, game publisher Gathering of 
Developers (G.O.D.), as well as support 
from AMD, Microsoft, Disc Makers, 
and GT Interactive, the event was 
underway. When I asked G.O.D. CEO 
M ike Wilson why his company decided 
to get involved, he simply stated that 
"it was something we couldn't afford 
not to do." 

The announcement of prize money 
for the six awards ($1,000 each for Best 
Programming, Best Art, Best Audio, 
Best Game Design, and Audience 
Award, plus $10,000 for the Best 
Overall Game), not to mention visibili- 
ty at the show, established the awards 
and energized the underground world 




Ben Sawyer is the co-founder of Digitalmill, Inc. (http://www.dmill.com). He is the co-author of the Game Developer's 
Marketplace and more than ten other computer books. His latest top-secret project is handling the business development for a foun- 
dation-funded simulation product aimed at the higher-education market. He can be reached at bsawyer@dmill.com. 
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of independent developers worldwide. 
In fact, entries were received from as 
far away as Pakistan, Russia, and 
Poland. With entries starting to come 
in, and sponsors and support in place, 
a panel of jurors was invited to help 
narrow all the entries down from near- 
ly 100 submissions to 15 finalists, each 
of whom would be invited to demon- 
strate their games at the event. 

By the time the awards were about to 
be handed out, a crowd of nearly 200 
people had assembled. Singularity 
Software's Fire and Darkness took the 
first honor, garnering the Audience 
Award which was determined by popu- 
lar ballot at theGDC. Vicarious Visions 
took the second award. Best Audio, for 
Terminus (a space combat RPG that was 
one of several titles to show that indies 
were very capable of putting out quali- 
ty real-time 3D work). All the better for 
the company's apparent inexperience 
in accepting awards, the developers at 
Vicarious Visions had another chance 
to practice their acceptance style when 
they later won the Best Programming 
award. This time they remembered to 
take their award with them, and 



entered the record books as the first 
game ever to be a two-time IGF winner. 

Andrew Leker of M ind Control 
Software accepted the award for Best 
Game Design for Resurrection. This 
game lay at the intersection of turn- 
based strategy and role-playing, and 
featured an interesting 3D landscape 
on which two opponent attempt to fan 
out their pieces and conquer the map. 
The Best Art award went to Poland- 
based Techland Software for their 
game. Crime Cities. Andrew Beard, who 
accepted for Techland, proclaimed 
upon accepting the award, "I'm 
pleased for Eastern Europe!" 
THE ENVELOPE, PLEASE. Finally, the time 
came for the big check — $10,000 for 
the overall winner. Fire and Darkness, 
the stunning 3D real-time strategy 
game from Singularity Software, which 
had earlier earned the Audience Award, 
was proclaimed the overall winner. The 
Singularity Software team, made up of 
a group of friends attending Carnegie 
Mellon University and their younger 
high school friends from McLean, 
Virginia, took home the big award. The 
game combines an advanced 3D graph- 



IGF WINNERS 



Best Overall Game: 

Fire and Darkness 

by Singularity Software 

Best Programming 

Terminus 

I by Vicarious Visions, Inc. 

' Best Audio 

I Terminus 
by Vicarious Visions, Inc. 

Best Game Design 

Resurrection 

Mind Control Software 

Best Visual Art 

Crime Cities 
Techland 

Audience Award 

IFire and Darkness 
by Singularity Software 



IGF FINALISTS 



ACIDIA 

by Whoola.com 

Boobies 
by Daedalon Interactive 
Entertainment 

BFRIS Zero-Gravity Fighter 
Combat 

by Aegis Simulation 
Technologies 

EverNight 
byVR.i 

Flagship: Champion 
by Keith Nemitz 

Food Chain 
by Cajun Games 

Journey Into The Brain 
by Morphonix 

Mind Rover 
by CogniToy 

Seed 

by Human Soft, Inc. 

Sleights 

by James Ferolo 

V.D. 

by Nothing Special 
Productions 



IGF SPONSORS 



AMDJl 




^7 Soitw 



dJ Ifiteracifve 
Software 



MictasoK 



IGF 2000 Information: 



The second annual IGF will take place 
next year at the Game Developers 
Conference. The specific submission 
deadlines for the upcoming event are as 
follows: 

• Applications for the event must be 
received by Wednesday, September i, 
1999. 

• Finalists (those invited to the GDC) 
will be announced Monday, November 
29, 1999. 

• The IGF winners will be announced at 
the Game Developers Conference, San 
Jose, Calif., March 9-13, 2000. 

Note that completed games will be 
required for both judging rounds, so 
mal<e sure your game is ready for play 
by this September. 

Updated information and IGF entry 
forms will be posted on the IGF website, 
at http://www.indiegames.com. 



ics engine, state-of-the-art networking 
technology, and a powerful combat 
simulation engine that Next Generation 
Online said "would make the game a 
legitimate competitor with Pandemic 
Studio's spectacular- 1 00 king Dark Reign 
2." After the ceremony, many of the 
other participants I spoke with admit- 
ted that they thought Fire and Darkness 
would win, indicating that the game 
was a winner even according to the 
team's IGF peers. 

"We'd like to thank the members of 
the Academy," the team joked as they 
proudly posed for press with their 
poster-sized check in hand. The three 
representatives of Singularity Software 
thanked all of their peers and the peo- 
ple who voted for their title. In thirty 
short minutes these formerly inexperi- 
enced indie game developers had 
become pros, thanking the members of 
the academy. No one ever said that 
game developers weren't quick learners. 

In the end Guha Bala, project lead for 
Vicarious Visions, summed up what it 
meant to win an award at the IGF: "We 
hope it means a deal !" With this state- 
ment, he seemed to speak for all of the 
finalists. For some of the finalists and 
winners, that hope may be realized. ■ 
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Read My Lips: 

Facial Animation Techniques 

This column follows the erratic path of a professional computer graphics 
developer, namely me. Anyone who has ever been in a professional produc- 
tion situation realizes that real-world coding these days requires a broad area 
of expertise.When this expertise is lacking, developers need to be humble 



FIGURE 1. The 12 classic Disney 
mouth positions. 




enough to look things up and turn to 
people around them who are more 
experienced in that particular area. 

As! continueto explore areas of 
graphics technology, I have attempt- 
ed to document the research and 
resources I have used in creating pro- 
jects for my company. My research 
demands change from month to 
month depending on what is needed 
at thetime. This month, I have the 
need to develop some facial anima- 
tion techniques, particularly lip sync. 
This means I need to shelve my 
physics research for a bit and get 
some other work done. I hope to get 
back to moments of inertia, and such, 
real soon. 



And Now for Something 
Completely Different 

My problem right now isfacial ani- 
mation. In particular, I need to 
know enough in order to create a pro- 
duction pathway and technology to 
display real-time lip sync. My first step 
when trying to develop new technolo- 



gy is to take a historic look at the prob- 
lem and examine previous solutions. 
Thefirst people! could think of who 
had explored facial animation in depth 
were the animators who created car- 
toon sand feature animation in the 
early days of Disney and Max Fleischer. 

Facial animation in games has built 
up on this tradition. Chiefly, this has 
been achieved through cut-scene 
movies animated using many of the 
same methods. Games I ike Full 
Throttle and The Curse of Monkey 
Island used facial animation for their 
2D cartoon characters in the same way 
that the Disney animators would 
have. More recently, games have 
begun to in elude some facial anima- 
tion in real-time 3D projects. Tomb 
Raider has had scenes in which the 3D 
characters pantomime the dialog, but 
the face is not actually animated. 
Grim Fandango uses texture anima- 
tion and mesh animation for a basic 
level of facial animation. Even console 
titles like Banjo Kazoo ie are experi- 
menting with real-time "lip-flap" 
without even having a dialog track. 
How do I leverage this tradition into 
my own project? 



Phonemes and Visemes 

No discussion of facial animation 
is possible without discussing 
phonemes. Jake Rodgers's article 
"Animating Facial Expressions" (Game 



Developer, November 1998) defined a 
phoneme as an abstract unit of the 
phonetic system of a language that 
corresponds to a set of similar speech 
sounds. More simply, phonemes are 
the individual sounds that makeup 
speech. A naive facial animation sys- 
tem may attempt to create a separate 
facial position for each phoneme. 
However, in English (at least where I 
speak it) there are about 35 
phonemes. Other regional dialects 
may add more. 

Now, that's a lot of facial positions 
to create and keep organized. Luckily, 
the Disney animators realized a long 



FIGURE 2. Side cut-out view of 
places of articulation. 




Jeff Lander often sounds like he knows what he's talking about. Actually, he's just 
lip-sync'd to someone who really know what's going on. Let him know you are on to 
the scam atjeffl@darwin3d.com 
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time ago that using all phonemes was 
overkill. When creating animation, an 
artist is not concerned with individual 
sounds, just how the mouth looks 
while making them. Fewer facial posi- 
tions are necessary to visually repre- 
sent speech since several sounds can 
be made with the same mouth posi- 
tion. These visual references to groups 
of phonemes are called vi semes. How 
do I know which phonemes to com- 
bine into one vi seme? Disney anima- 
tors relied on a chart of 12 archetypal 
mouth positions to represent speech as 
you can see in Figure 1. 

Each mouth position or viseme rep- 
resented one or more phonemes. This 
reference chart became a standard 
method of creating animation. Asa 
game developer, however, I am con- 
cerned with the number of positions I 
need to support. What if my game 
only has room for eight vi semes? What 
if I could support 15 visemes? Would it 
look better? 

Throughout my career, I have seen 
many facial animation guidelines with 



different numbers of visemes and dif- 
ferent organizations of phonemes. 
They all seem to be similar to the 
Disney 12, but also seem I ike they 
involved animators talking to a mirror 
and doing some guessing. 

I wanted to establish a method that 
would be optimal for whatever num- 
ber of visemes I wanted to support. 
Along with the animator's eye for 
mouth positions, there are the more 
scientific models that reduce sounds 
into visual components. Forthedeaf 
community, which does not hear 
phonemes, spoken language recogni- 
tion relies entirely on lip reading. Lip- 
reading samples base speech recogni- 
tion on 18 speech postures. Some of 
these mouth postures show very subtle 
differences that a hearing individual 
may not see. 

So, the Disney 12 and the lip read- 
ing 18 area good place to start. 
However, making sense of the organi- 
zation of th ese I i sts req u i res a I ook at 
what is physically going on when we 
speak. I am fortunate to have a linguist 



right in theoffice. It'stimes like this 
when it helps to know people in all 
sorts of fields, no matter how obscure. 



Science Break 

The field of linguistics, specifically 
phonetics, compares phonemes 
according to their actual physical 
attributes. The grouping does not real- 
ly concentrate on the visual aspects, 
as sounds rely on things going on in 
the throat and in the mouth, as well 
as on thelips. But, perhaps this can 
help me organize the phonemes a bit. 

Sounds can be categorized accord- 
ing to voicing, manner of articulation 
(airflow), and the places of articula- 
tion. There are more, but these will 
get the job done. As speakers of 
English, we automatically create 
sounds correctly without thinking 
about what isgoing on inside the 
mouth. Yet, when we see a bad anima- 
tion, we know it doesn't look quite 
right although we may not know why. 



CHART 1 . American English ptioneme summary chart. 



ORAL STOPS 

(airflow closed off) 

FRICATIVES 

(airflow partially 
closed and turbulent) 

AFFRICATE 

(combines a stop 
then fricative) 

APPROXIMATE 

(airflow narrowed, 
not turbulent) 

NASAL STOPS 



VOWELS (airflow free flowing 



V 


buy 


VL 


P 


e 


V 






VL 






V 






VL 






c 






L 








my 




beat 

bit 

bait 

bet 

bat 



why 



fie 



FRONT CENTRAL BACK 



but 



boot 
book 
boat 

bought 



tliy 

tliigh 



lie 



die 
tie 
zion 

sigh 



rye 



nigh 



hag 
hacl^ 



uli-oh 



sliy 

jive 

cliime 



yes 



liigh 



hang 



V = Voiced 
VL = Voiceless 
C = Central 
L = Lateral 
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FIGURE 3a. Side view of the sound 
[bias in "buy." 



FIGURE 3b. Side view of the sound 
[phasin "pie." , 



FIGURE 3c. Side view of the sound 
[m],as in "my." 




With the information below, you will 
be equipped to know why things look 
wrong. Now for some group participa- 
tion. This is an interactive article. Go 
on, no one is looking. The categories 
we wan t to exam i n e are: 
Voiced vs. Voiceless. Put your hand on 
your throat and say something. You 
can feel an intermittent vibration. Now 
say, "p-at, b-at, p-at, b-at," (emphasiz- 
ing the initial consonant). Looking at 
the face, there is no visual difference 
between voiced and voiceless sounds. 
In some sounds the vocal cords are 
vibrating together (b-voiced) and in 
some the vocal cords are apart (p- 
voiceless). This isan automatic no- 
brainer as far as reducing sounds into 
oneviseme. Any pair of sounds that is 
on I y d i f f eren t becau se of vo i ci n g can be 
reduced to the same vi seme. In English, 
that eliminates eight phonemes. 
Nasal vs. oral. Put your fingers on your 
nose. Slowly say "momentary." You 
can feel your nose vibrating when you 
are saying the "m." Some sounds are 
said through the nasal cavity, but most 
are said through the oral cavity. These 
are also not visibly different. So again, 
we have an automatic reduction in 
phonemes. All three nasal sounds in 
English can be included in the oral 
viseme counterpart. 
Manners OF Speech. Sounds can also be 
differentiated by the amount of open- 
ing through the oral tract. These also 
do not offer a visible clue, but are very 
important for categorizing phonemes. 
Sounds that have complete closure of 



theairstream are called stops. Sounds 
that have a partially obstructed closure 
and turbulent airflow are called frica- 
tives. A sound that combines a 
stop/fricative is called an affricate. 
Sounds that have a narrowing of the 
vocal tract, but no turbulent airflow, 
are called approximates. And then 
th ere are sou n ds th at h ave rel ati vel y 
no obstruction of the airflow; these are 
the vowel s. 

Places of Articulation. This involves 
where thesound is being made in the 
mouth. This is where the visible differ- 
ences occur. There are several places 
of articulation (see Figure 2) involving 
the lips, teeth, tongue, and stuff in the 
back of the mouth (the palate, velum, 
and glottis) for the consonants. Vowel 
placement is based on the relative 
height of the tongue and whether the 
tongue is more front or back in the 
mouth. A differentiating factor not 
listed in Chart 1 is lip rounding. This 
is not associated with any particular 
place of articulation and will be 
addressed below. Whew. 

As I said, there are 35 phonemes in 
my dialect of American English. You 
may have more. Chart 1 is a summary 
of these phonemes. Read the chart 
from the front of the mouth to the 
back of the mouth. Try saying each of 
the words that illustrate the phoneme 
that is in bold. Havea look in the mir- 
ror and see what is going on as well as 
feel what is going on inside the head. 
By using the distinction of voicing and 
o ral / n asal , we h ave al ready el i m i n ated 



11 phonemes. Let's continue the 
reduction of phonemes into the usable 
vi semes. 

Take It to the Limit 

Accordi ng to the chart, there are 
three bi labials, which are sounds 
made with both lips. They are [b], [p], 
and [m]. According to the Figures 3a, 
3b, and 3c they have different attribut- 
es inside the mouth. Band P only dif- 
fer in that the B makes use of the vocal 
cords and P does not. The M sound is 
nasal and voiced so it is similar to the 
B sound, but it is a nasal sound. The 
cool thing about these sounds is that 
wh i I e th ere are d i ff eren ces i n si de th e 
mouth, visually there is no difference. 
If you look in a mirror and say "buy," 
"pie," and "my" they all look identi- 
cal. We have reduced three phonemes 
into oneviseme. 

Whileyou're working, remember 
that you are thinking with respect to 
sounds (phonemes), not letters. In 
many cases a phoneme is made up of 
multiple letters. So, if we go through 
Chart 1, we can continue to reduce the 
35 phonemes into 13 visemes. For the 
most part, the visemes are categorized 
along the I ines of the Places of 
Articulation (with theexception of [r]). 

Take a look at the sidebar on 
visemes. It describes the look of each 
phoneme in American English. The 
only phonemenot listed is[h]. "In 
English, 'h' acts I ike a consonant, but 
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from an articulatory point of view it is 
simply the voice! ess counterpart of the 
following vowel." (Ladefoged, 1982:33- 
4). In other words, treat [h] I ike the 
vowel that comes after it. 

To see how helpful this information 
can be when animating a face take a 
word like "hack." It has four letters, 
three phonemes, and only two vi semes 
(13 and 9 in the sidebar). 

Say that you don't have enough space 
to include 13 visemesand whatever 
emotionsyou want expressed. Well, by 
using Chart 1 and the list of visemesin 
thesidebar, you can make logical deci- 
sions of whereto cut. For example. If 
you only have room for 12 visemes, you 
can combine vi seme 5 and 6 or 6 and 7 
below. Forllvisemes, continue com- 
bining visemes by incorporating vi seme 
7 and 9 below. For 10, combine visemes 
2 and 3. For 9, combines with the new 



I 



Visemes 



1* [p, b, m] - Closed lips. 
2* [w] &[boot] - Pursed lips. 
3* [r*] & [book] - Rounded open lips 
with corner of lips slightly pucl<ered. If 
you look at Chart i, [r] is made in the 
same place in the mouth as the sounds 
of #7 below. One of the attributes not 
denoted in the chart is lip rounding. If 
[r] is at the beginning of a word, then it 
fits here. Try saying "right" vs. "car." 
4* [v] & [f ] - Lower lip drawn up to 
upper teeth. 

5* [thy] & [thigh] - Tongue between 

teeth, no gaps on sides. 

6* [I] - Tip of tongue behind open 

teeth, gaps on sides. 

7« [d,t,z,s,r*,n] - Relaxed mouth with 

mostly closed teeth with pinl<ness of 

tongue behind teeth (tip of tongue on 

ridge behind upper teeth). 

8. [vision, shy, jive, chime] Slightly 

open mouth with mostly closed teeth 

and corners of lips slightly tightened. 

9« [y, g, !<, hang, uh-oh] - Slightly open 

mouth with mostly closed teeth. 

10* [beat, bit] - Wide, slightly open 

mouth. 

11* [bait, bet, but] - Neutral mouth with 
slightly parted teeth and slightly 
dropped jaw. 

12* [boat] - very round lips, slight 
dropped jaw. 

13* [bat, bought] - open mouth with 
very dropped jaw. 



viseme7/9. For 8, combine 11 and 13. 

If I were really pressed for space, I 
could keep combining and drop this list 
down further. Most drastic would be 
three frames (Open, Closed, and Pursed 
as in boot) or even a simple two frames 
of lip flap open and closed. In thiscase 
you would just alternate between 
opened and closed once in a while. But 
that isn't very fun or realistic, is it? 

Art Issues 

These viseme descri ptions are enough 
to realistically represent speech. 
However, the use of individual visemes 
is more an artistic judgement then a 
hard rule. When speaking, peopletend 
to slur phonemes together. They do not 
clearly articulate each phoneme all the 
time. Also, thelookof a viseme can 
change depending on the visemes that 
surround it. For example, the Disney 
gu i del i n es descri be th e use of a si i gh tl y 
different viseme for B, P, and M if they 
precede the ea sound as in beat. 

This dependency on surrounding 
sounds is called co-articulation and 
makes viseme choice more compi icated. 
Th i s i s on e reason th at th e automati c 
phoneme recognition software in some 
packages doesn't always provide realistic 
results. Smooth interpolation between 
viseme keyframes can help, but this 
alone may not be good enough. In 
many cases, it requires an artistic judge- 
ment for which viseme really looks best. 
In computer animation, realistic looks 
are all that matter. So, when you work, 
put in the viseme that looks best. 

Emphasis and exaggeration are also 
very important in animation. You may 
wish to punch up a sound by the use of 
a viseme to punctuate the animation. 
This emphasis along with theaddition 




• Culhane, Shamus. Animation from 
Script to Screen. New York: St. Martin's 
Press, 1988. 

• Ladefoged, Peter. A Course in 
Ptionetics. San Diego: Harcourt Brace 
jovanovich, 1982. 

• Maestri, George, [digital] Ctiaracter 
Animation. Indianapolis: New Riders 
Publishing, 1996. 

• Parl<e, Frederic I. and Keith Waters 
Computer Facial Animation. Wellesley 
A. K. Peters, 1996. 



1 



of secondary animation to express emo- 
tion iskey to a believable sequence. 

In addition to these viseme frames, 
you will want to have a neutral frame 
that you can use for pauses. In fast 
speech, you may not want to add the 
neutral frame between all words, but in 
general it gives good visual cues to sen- 
tence boundaries. 



So What Do I Do with This Stuff? 

So far, I have been discussing issues 
that only seem important to the 
artists working on the facial animation. 
If the only use of facial animation in 
your project isfor pre-rendered cut 
scenes, this may be true. However, I 
believe facial animation will become an 
important aspect in real-time 3D ren- 
dering as we take character simulation 
to the next level. This requires a close 
relationship between the art assets and 
engine features. As a technical lead on a 
cutting-edge 3D project, you will be 
required to create the production path- 
way that the artists will use to create 
assets. You will be responsible for decid- 
ing how many visemes the engine can 
support and the manner in which the 
meshes must be created. Having a clear 
understanding of what goes into the 
creation of the assets will allow you to 
interface more effectively with those 
creating the assets. 

However, even with the viseme count 
I am still not ready to set the artists 
loose creating my viseme frames. There 
are several basic enginedecisionsthat I 
must make before modeling begins. 
Unfortunately, I will have to wait until 
next month to dig into that. Until then, 
think back on my 3D morphing column 
("M ighty Morphing Mesh Machine," 
December 1998) as well as last year's 
skeletal deformation column ("Skin 
Them Bones," Graphic Content, May 
1998) and see if you can get a jump on 
the rest of the class. M 
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To Build or Not to Build 




hat is the question that many development houses are pondering today. 
And with ever-in creasing frequency, developers are turning to outsourcing 
for much of their digital content creation needs. Some of the biggest 
names in the industry have brokered deals where the bulk of their 



modeling needs are handled out-of- 
house, and the tactic is paying off in 
shorter time to market, and a smoother 
production pipeline. 

Thismonth, we'll take a close look at 
some of the major players in the mar- 
ket, and look at some examples of how 
their products have evolved alongside 
thegaming industry. 

Why Are Ue Seeing the Shift? 

There are three main reasons for the 
recent trend in outsourcing. First, 
the hardware we deal with has become 
extremely capable, and over the past 
few years we've seen a shift from 2D 
and 2.5 D games to fully 3D, immersive 
environments. This refocusing of artis- 
tic demand is necessitating a massive 
amount of 3D work to fill theenviron- 
ments of today's games. And it's not 
uncommon to havefour or five model- 
ers dedicated just to building environ- 
mental models and architecture. The 
second factor is the size of the talent 
pool of good 3D artists. There just 
aren't enough of us out thereto meet 
the constantly increasing demand for 
quality 3D work. In many cases, as you 
will see shortly, developers have no 
option other than to outsource. Finally, 
the quality level of the outsourcing 
community has risen dramatically 
within the last few years. Modeling 
houses are no longer the black sheep of 
thedigital artist community. Recent 
Hollywood exposure as well as big 
name entertainment titles have helped 
th ese teams to so I i d i fy th ei r respect i ve 
reputations for providing quality work 
in a timely manner. Outsourcing has 



become a more than viableoption. 

Who Are the Major Players? 

Although there are myriad small 
companies dedicated to providing 
modeling services for both the film and 
entertainment industries, there area 
select few who have risen to dominate 
thefield. 

Viewpoint Datalabs. Widely recognized 
as the industry leader in digital content 
creation. Viewpoint isfast becoming 
the Microsoft of modeling. Originally 
known for its extensive database of 
wireframe meshes, the company has 
been rapidly expanding its operations 
to include custom modeling and ani- 
mation services, and very recently, the 
development of a texture database for 
3D models. Viewpoint's client list reads 
likea who'swho in film and video 
games. Most notably, thedigital lizard 

in therecently ^ 

released film 
Godzilla and the 
entire cast of GT's 
Oddworld: Abe's 
Oddysee stand as 
impressive trib- 
utes to the team's 
custom modeling 
capabilities. And 
with the recent 
acquisition of the 
distribution 
rights for the 
REM Model Bank, 
Viewpoint's 
library of digital 
content remains 
unparalleled in 



the industry. Figure 1 isa highly 
detailed model of the the statue of 
Abraham Lincoln in the Lincoln 
Memorial, and demonstrates the high 
fidelity of artchitectural accuracy for 
which Viewpoint is well-known. Figure 
2 shows a rhinoceros model from the 
REM Model Bank, the distribution 
rights to which Viewpoint now owns. 
Notethe painstaking attention to 
detail in the texture work. This is what 
has set the M odd Bank apart from its 
contemporaries. 

Zygote. Formed back in 1994 by former 
Viewpoint employees, this Utah -based 
company was founded by a group of 
industry professionals who have main- 
tained their niche in the area of organic 
modeling. Although Zygote's offerings 
and experience don't match 
Viewpoint's, it isstill a substantial play- 
er. Its clients have included some of the 
biggest names in the industry, from 
DreamWorks and Digital Domain to 





I I 



FIGURE 1 . This detailed model of Abe Lincoln demonstrates 
Viewpoint's hiighi-fidelity arctiitectural accuracy. 
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FIGURE 2 . The painstaking attention to detail in this Rhino is what sets Model 
Banl< apart from its contemporaries. 



Accolade and Pixar. With its expertise in 
organic modeling techniques, it is prob- 
ably the second- largest supplier of digi- 
tal content in the industry. 

Zygote recently developed of a line of 
fully textured and an i matable human - 
oids. The models, created specifically 
for use with 3D Studio Max and 
Character Studio, come attached to a 
biped skeleton, which is weighted and 
ready for animation. An example of this 
is shown in Figure 3, in which a nicely 
modeled human is displayed with its 
corresponding wireframe and biped 
skeleton. Note theorganic blending 
characteristics of NURBS models; the 
I ack of text u re wo rk i s m ad e u p f o r i n 
the detailed nature of the geometry. 
Other relative newcomers to the scene 
include Paraform and 3D Cafe. 



Weighing the Options 



Whether to go with an outsourc- 
ing scheme is a decision to be 
made carefully, no matter what the sit- 
uation. But it can prove to be the best 
and sometimes only option, depending 
on the circumstances. And you don't 
always have to depend on the stock 
digital libraries that Zygote and 
Viewpoint offer. Both have also 
demonstrated a robust capability for 
custom modeling in thegaming indus- 
try, which is where they get most of 
their exposure. To get a better feel for 
the custom modeling process, we inter- 
viewed some of Viewpoint's most 
recent clients, and found that, without 



exception, they viewed the entire expe- 
rience as a positive one. 
GvsE Study i: Gauntlet: Legends. This 
remake of the 1980s arcade hit was 
recently released by Atari. Steve 
Caterson, the project's art director, 
went to Viewpoint in the latter stages 
of production to get high-resolution 
versions of the in-game characters cre- 
ated. According to Steve, off-loading 
these tasks at the back end of the pro- 
ject en abl ed h i s team to focus al I of 
their creative energies on completing 
the product. Atari got a lot for its out- 
sourcing dol I ars as wel I , si n ce th e mod- 
els were subsequently used for a num- 
ber of marketing and promotional 
images, cabinet graphics, screens graph- 
ics, and full-motion videos. 

For Legends, Steve was able to work 
out a pi pel i ne with the Vi ewpoi nt team 
that proved extremely efficient. 
Initially, concept sketches were sent off 
to Viewpoint's modeling teams, with 
any questions resolved via telephone or 
e-mai I . Vi ewpoi nt's model ers began 
building the models and sending ortho- 
graphic renders of the characters back to 
Steve, who then 
made changes to 
the images in 
Photoshop to 
indicate thedirec- 
tion he wanted 
the modeling 
team to take 
(Figure 4). This 
back-and-forth 



texturing stage until thefinal models 
were completed (Figures 5 and 6). 
Eventually, as the relationship and com- 
munication evolved between Steve and 
t h e V i ewpo i n t team , t h ey were abl e to 
work out artistic changes via telephone 
only. 

I n retrospect, the cost of the process, 
although substantial, paid big returns in 
quality and speed. The Viewpoint team 
was ableto get thecontent created 
much faster than the in-house team 
could have. And the Viewpoint team 
displayed a willingness to accept 
changes and rework and edit the models 
until thecontent was perfect. In Steve's 
words, "With other contractors I've 
worked with, when you ask for 'A' they 
give you just barely what you ask for, 
but no more. And when you ask for 
changes, they look at you like you're 
trying to kill their firstborn. With 
Viewpoint, the modelers and animators 
were totally enthusiastic about what 
they were doing. I had animators calling 
me up late at night to say they had 
stayed an extra few hours to add in cool 
features that we didn't even know we 
would need. With Viewpoint, I got what 
I asked for, and then a whole lot more." 
Case Study 2: Civilization: Gvll to Power. 
This latest offering in the groundbreak- 
ing Civilization franchise is being pub- 
lished by Activision. Civilization: Call 
TO Power offers innovative features 
such as stacked combat and battle view. 
The game's time frame runs from 4000 
BC to AD 3000, giving players the 
opportunity to build far into the future 
and enjoy new units, wonders, and 
technologies. But the increased func- 
tionality and game play came at a high 
development price. Each unit, city 
improvement, and civilization advance 
would be represented by a pre-rendered, 
spinning 3D object. Mark Lamia, the 
game's producer, was looking at more 
than ten man -years of modeling work 
just to create the 3D versions of these 




iteration contin- 
ued through the 



FIGURE 3 . An example of Zygote's animatable humanoids. 
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black-and-white concept pieces, and 
eventually moving to color comps, the 
Activision team put together the 
resource material necessary for 
Viewpoint to complete the task. This 
process turned out to have side benefits 
since, as Mark put it, "Having to direct 
someone remotely meant that the con- 
cept material had to be clear and con- 
cise, with no room for misinterpreta- 
tion. It really forced us to be organized 
and to examine the different aspects of 
each object in extreme detail — some- 
thing that, if we did the work in-house, 
we would probably have been more lax 
about doing." The project further bene- 
fited from the use of several stock mod- 
elsfrom the Viewpoint catalog. "Since 
thegame takes placein large part overa 
real -world timeframe," Mark added, 
"several of the architectural objects in 
the Viewpoint library were directly 
applicableto our project." 

The Viewpoint team produced several 
hundred animating sprites, each onea 
rotating view of an in -game object, in a 
little under ten months. And it cost a 
fraction of the projected in-house strate- 
gy. The game was completed on time 
and under budget on the resource side of 
the house, and everyone benefited from 
the experience. 



FIGURE 4 . The art director for Atari's Gauntlet: Legends used ttie Viewpoint team 
to turn concept pieces and Photoshop edits into highly detailed models. 



objects. From a budgetary standpoint, 
thistask, if done in-house, would have 
cost the company well over $500,000. 
Mark needed a solution that was faster 
and cheaper than what he could do 
with his own team. Here again, out- 
sourcing solved the problems that the 
in-house resources just couldn't handle. 
However, this was a much bigger prob- 
lem than that faced by the Atari team. 
Instead of generating content for mar- 
keting publications, Viewpoint'steam 
of modelers needed the resources to 
actually build thegame. There was far 
less room for error — if the ploy failed, 
theproduct wouldn't ship. Faced with 
th e ch al I en ge of gett i n g al I th i s artwo rk 
remotely produced under budget and 
on time, Mark worked closely with his 
point of contact at Viewpoint to orga- 
nize the project around milestones 
which separated the hundreds of mod- 
els into manageable chunks. 



Aside from the sheer bulk of the work, 
the development process was very simi- 
lar to Atari's situation. Starting with 



Tips to Remember When Outsourcing 

In hindsight, both Mark and Steve 
had several recommendations for a 
team looking to contract work to an 
outside production facility. 
1. Always speak your mind about 




FIGURE 5. A concept si<etch and one of Viewpoint's finished Gauntlet models. 
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what you want. Don't mince words, and 
be tactful yet blunt. If you don't like 
what you see, the contractor probably 
won't fix the problem on his or her own. 
You are the one paying for the service, 
and as the customer, you are always 
right. 

2. Prepare, prepare, prepare. It's always 
better to give the contracting team too 
much information than not enough. 
The level of ambiguity in your art direc- 
tion is directly linked to the level of 
uncertainty in thefinished product. If 
you don't know what you want, the con- 
tractor can't know either. 

3. Engage the contractor in as much 
communication as possible. Agree on 
milestone points for each model (at least 
two, one at the modeling stage and one at 
th e textu ri n g stage, but th e more th e bet- 
ter), and plan plenty of time for iterations, 
especi al I y at t h e begi nningofthe process. 
Once you have developed a rapport with 
your contractor, the process will go much 
faster and require I ess footwork on thefrontend. 

4. For large projects, designate someone in-house as the 
asset manager, responsible for maintaining a database show- 
ing the status of modelsin theapproval process. Thisperson 
should be responsible for up- and downloads between you 




FIGURE 6. Another concept sketch and finished model for Gauntlet 



and the contractor, and should keep tabs on where each piece 
of content fits into the process. This can bean extremely 
time-consuming task, and should not be left to chance, as 
contractors may or may not take this responsibility upon 
themselves. 



Redefining Real Time? 

Researching this article, I came across very few instances 
where custom modeling was done for real-time 3D assets. 
Th e feed back I got seemed to i n d i cate th at wh i I e t h e h i gh -reso- 
lution modeling and rendering were tasks which theart direc- 
tors felt could be effectively managed out of house, the genera- 
tion of low-polygon real-time content was something better 
left to the in-house teams. The reasons for this trend varied, 
bu t th e u n derl y i n g i m pressi on was th at th e real -ti me con ten t 
could be developed rapidly in-house, and since real-time mod- 
eling techniques differ largely from the high resolution model- 
ing methods used to generate cutscene characters, the teams 
fdt more comfortable doing the work themselves. 

Currently, a run-of-the-mill 3D engine will put out any- 
where from 2,000 to 6,000 polygons on-screen at any given 
time. Consider that in a standard character- based game, 
about half of this polygon budget is spent on characters, 
meaning anywhere from 1,000 to 3,000 polygons in charac- 
ter models alone. There are projects currently in develop- 
ment with target on-screen polygon counts of 50,000 and 
higher. At a similar ratio, upwards of 25,000 polygons will be 
devoted to character models. This means that many of the 
high-resolution models generated by companies I ike Zygote 
and Viewpoint will have direct application for real-time 3D 
games, and the hard ware is only getting better. It seems obvi- 
ous then, that with the constantly increasing capability of 
gaming platforms, and the correspondingly complex scene 
requirements for 3D content, outsourcing will become a 
much larger aspect of game development. ■ 
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3Dlabs: Pioneering 3D 
Isn't Always Profitable 




ince 1993, 3D labs has been pioneering and evangelizing 3D graphics on 
the desktop. Even before it had a product offering for the mainstream 
desktop, as it was on the cusp of launching its workstation graphics prod- 
uct, it was active among game developers and in the general PC market. 



In fact, 3Dlabs has always managed 
to maintain a high profile in the 
industry, luring Creative Labs, Intel, 
and Texas Instruments into its 
embrace, and at one point having 
practically every major graphics board 
vendor in the world dealing with it. 
Today, the company may not be so 
hot. It faces its biggest challenge yet, 
one that may make or break this pio- 
neer of desktop 3D. That challenge is 
to win the hearts and minds of game 
players as well as the game develop- 
ment community. 



A History Lesson 



There is no doubt that BDIabs's 
pedigree is a good one. The com- 
pany began life as Du Pont Pixel, a sub- 
sidiary of Du Pont, the large, well- 
known technology conglomerate. Du 
Pont Pixel was specializing in supply- 
ing GL-based 3D graphics tools and 
applications on SPARC, and was a 
founding member of Sun's Open 
Graphics Initiative, as well asoneof 
thefirst licenseesof OpenGL. 

In March 1994, Du Pont Pixel's 
senior management took the assets 
that they needed and formed the 
nucleus of 3D labs using assets they had 
acquired from a previous company. 
The initial research which led to the 
development of the company's Glint 
technology actually began in 1993 asa 
small development effort within Du 



Pont Pixel. Management at 3Dlabs was 
eager to take this technology into the 
W Intel market, which was still consid- 
ered a highly risky maneuver. In 1993, 
the idea that the PC was goi ng to 
replace the workstation market was still 
heresy. 

In late 1993 and early 1994, a small 
group of engineers within Du Pont 
Pixel undertook initial architectural 
design and product definition. The 
company substantially expanded this 
development effort and significantly 
increased the development team, cul- 
minating in thecompletion of the 
Glint 300SX processor in the fourth 
quarter of 1994. G I i nt got off to a 
rocky start. It was the first product to 
hit the PC workstation market that 
met the standards of application ven- 
dors, but it lacked simple features 
such as support for certain texture 
mapping functions. Despite misgiv- 
ings about 3D I abs's silicon, almost 
every graphics board vendor with a 
yen for the PC workstation market 
signed on with the company. By 1996, 
3D labs owned 90 percent of the PC 
workstation graphics market. 

In connection with the acquisition of 
assets from Du Pont, 3D labs agreed to 
pay Du Pont Pixel two percent of its 
total revenues each year that the com- 
pany'stotal revenues exceed $70 mil- 
lion until the year 2000. Very shortly 
thereafter, on April 18, 1994, 3D I abs's 
management completed the buyout of 
Du Pont Pixel from the Du Pont Corp- 
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oration and entered into a license agree- 
ment with Creative Labs, under which 
Creative licensed from 3D labs certain 
Glint technology. For this license. 
Creative paid 3Dlabsan initial license 
fee of $1 million. In July 1995, Creative 
paid the company a nonrefundable 
advance royalty of an additional $1 mil- 
lion in connection with the develop- 
ment of certain products and reductions 
in future mini mum royalties. Moreover, 
Creative agreed to pay minimum annu- 
al royalties through theyear2000. 

In return, 3DlabsdeRaveloped the 
Gigi chipset for use in Creative's3D 
Graphics Blaster. Creative also paid the 
company approximately $1 million in 
CO n tract en gi n eer i n g fees f o r t h e d evel - 
opment of Gigi. 3D labs retained exclu- 
sive rights to the intellectual property 
included in Gigi, and Creative had the 
exclusiveright to sell Gigi until 1998 
along with the right to sublicense. The 
term of the I i cense was seven years. 

At thetime, many peoplethought 
Creative was going to sew up the 3D 
graphics market the way it had the 
audio market, but neither the technol- 
ogy nor the support of game develop- 
ers was there. However, in 1995, 
Creative also licensed the Permedia 
technology from 3D labs in considera- 
tion for paying a portion of the Per- 
media development costs. In addition, 
3Dlabs agreed to incorporate certain 
features into the Permedia chip specifi- 
cally for Creative, and Creative cross- 
licensed certain technology to 3D labs, 
mostly on the API and driver front. 

By thetime 3Dlabs had its initial 
public offering in 1996, Creative and 
Intel both had shares in the company, 
which was a measure of the value each 
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(In thousands of dollars) 


1995 


1996 


1997 


400ft 


Revenues 


^ ^ ^ 

6,594 


^ ^ ^ 

19,695 


69,129 


42,72 


1 


Operating Expenses 

1 


7,992 


16,904 


52,712 


68,54 


7 


Income Before 
Taxes 


-1,358 


3,091 


17,882 


-30,753 


SDlabs's revenues and profits for 1995-1998. How hard will they get hit? 



company placed on the BDIabs tech- 
nology. Intel wanted to see3Dlabs's3D 
efforts go into its platform, and 3Dlabs 
wanted to be tightly bound to the Intel 
platform in the way it had been to 
Sun's in its early days. Creative was to 
provide the company mass market 
exposure, but without the burden of 
building a consumer and mainstream 
graphics business. I don't think that at 
the ti me there were many peopi e out- 
side of the industry who didn't associ- 
ate the PC 3D market exclusively with 
3D labs. You have to give 3D labs a lot 
of credit for its evangelizing efforts. 
The company could so easily have cho- 
sen to focus on the high-end at the 
exclusion of all else, but it was ambi- 
tious. Or was it hubris? 



The Need for Speed — Game Speed 

Permedia should have opened up 
the doors for 3Dlabs in the main- 
stream. But it didn't hit the market in 
its first iteration, and missed out on 
performance and some essential fea- 
tures. By thetime Permedia 2 came 
out, the consumer market was awash in 
3dfx and the promise of Rendition. In 
fact, Permedia 2 became 3D I abs's worst 
enemy, taking a chunk of its Glint 
board business at much lower costs. So, 
if you lookat 3Dlabsin 1998 you find a 
company that cannibalized its own 
workstation graphics business with a 
lower-cost, lower-profit-margin prod- 
uct. In addition, the company's efforts 
to raise the performance bar on its high 
end with its next-generation Glint 
Gamma were thwarted by competitors 
Evans and Sutherland, Intergraph, and 
a small company called Dynamic 
Pictures. To make matters even worse, 
the company was not getting much 
mileage out of its technology in the 
mainstream, where S3, ATI, Matrox, 



Nvidia, and 3dfx were doing their 
thing, and where Intel was driving 
prices down with its chips. 

When Evans and Sutherland bought 
oneof its main customers, 
Accel graphics, 3Dlabs acquired oneof 
its competitors that was already a verti- 
cally integrated board vendor. 
Dynamic Pictures. In effect, the high - 
end graphics market did what it has 
alwaysdonefor the industry: it trickled 
down technologies and business direc- 
tions. You can trace the merger of 3dfx 
and STB back to the point when Evans 
and Sutherland acquired Accel graphics, 
and caught the industry flat-footed. 
The chip and board vendors knew that 
the industry was going to consolidate 
with the coming of Intel, and the suc- 
cessful paths trodden by ATI and 
Matrox, but no one wanted to make 
the first move. Once the floodgates 
opened, however, everyone started 
making their moves. Of course, 
3D I abs's maneuver was part forward- 
looking and part defensive. The com- 
pany was still determined to get into 
the mainstream graphics market, but 
could not see a way of doing so with a 
board business. Actually, the problem 
may have had more to do with the fact 
that 3D labs couldn't afford to buy a 
board vendor like Diamond 
Multimedia, and thereby retain its 
autonomy. 

As a result, Permedia 3 now spear- 
heads 3D I abs's assault on the desktop. 
It launched at CeBIT, Europe's largest 
computer show, and simultaneously at 
the GDC. But it's very late — by six 
months or a year, depending on whom 
you talk to. And it may not be a match 
for Voodoo3, TNT 2, or even Savage4 
in the market. In fact, 3Dlabshasan 
uphill battle to get Permedia 3 con- 
sumer recognition. Most board ven- 
dors are committed to taking TNT 2 
into the high-end gaming segment. 



and beating up on 3dfx. S3 provides 
the vendors with a budget-priced chip, 
and a good one at that. Where does 
Permedia 3 fit if it's not significantly 
faster than TNT 2? 



Permedia 3: There's the Rub 

On the surface, Permedia 3 is not a 
bad chip. Whether it can take on 
the likes of Voodoo3 and TNT 2 is sub- 
ject to some debate, but it's also not 
certain whether it deserves to be 
pigeonholed into the same market as 
Permedia 2. Ultimately for 3D labs, 
Permedia 3 must make some effective 
headway into the consumer space, and 
that means winning over the game 
players. Without this crucial demo- 
graphic behind it, Permedia 3 loses 
any luster it might have, and 3Dlabs 
knows this. It doesn't help that 
3Dlabs's fortunes have taken such a hit 
in the past eighteen months. The com- 
pany is almost ripe for takeover, but 
partners for the company are few and 
far between. A good run in the market 
by Permedia 3 would change all that 
dramatically. 

Permedia 3 has oneunique selling 
point: virtual textures. It's worth noting 
that Matrox used the functionality of its 
bump mapping feature on theG400 in 
thesamevein when they launched it at 
theGDC. Will it be enough, coupled 
with all of the other standard 3D fea- 
tures of the Permedia 3? I'm not sure 
that it will. 

As of this writing, 3Dlabs didn't 
have any significant brand-name 
board vendors signed on for Permedia 
3. Part of the reason, as I've said, is 
that the company doesn't want to see 
its flagship product slotted in between 
TNT 2 and Savage4. But 3Dlabs needs 
some glory, and quick. I don't believe 
the company will shuffle off its mortal 
coil anytime soon, but it will be sub- 
ject to th e si i n gs an d arrows of m i sfor- 
tune if it doesn't boost the sex appeal 
of the Permedia 3. 

You can't count 3Dlabs out yet. It 
blazed a trail, and brazenly miscued on 
major product initiatives, yet it re- 
mains a strong 3D brand, and the 
company has the ability to muster up 
some impressive engineering re- 
sources. It also has some strengths in 
supporting game developers. It just 
needs sex appeal. ■ 
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The Front Line Awards are this publication's annual nod 
to the products and companies that made the lives of 
game developers easier. It's how we say thanks to the peo- 
ple and companies who make great game development 
products. 

Admittedly, there were times over the past year when 
many of usjudging products for these awards discussed 
thedifficulty of pinpointing which game technologies 
were the most innovative. After all, the rate of change in 

AwardU 

the industry is phenomenal, and it's not easy to proclaim 
specific products as "winners" in thisregard. However, 
despite these inherent difficulties, we feel that the hard- 
ware and software on the foil owing pages are worthy of 
praise and recognition. 

Products Big and Little Alike 

Years ago, William McGowan, then CEO of MCI 
Communications, was quoted assaying, "signifi- 
cant progress doesn't come from the formal plan- 
ning process of an American corporation — it comes from 
a couple of guys doing something that hasn't been set 
down on a list." I can't think an industry that proves this 
sentiment more than game development. Much of the 
interesting work in thefield of game development tech- 
nology is being done by smaller or less well-known compa- 
nies such asSN Systems, Darkling Simulations, and NxN 
Digital Entertainment. These companies understand the 
industry, see where gaps in technology are, and then cre- 
ate products that fill those voids. Thecombination of 
industry comprehension and pragmatic product develop- 
ment is powerful. 

Of course, some of the stalwarts of the industry were rec- 
ogn i zed as wel I . Th e el egan ce of M aya earn ed an award for 
its creator, Alias|Wavefront. Diamond M ultimedia and 
Creative Labs were recognized for their contributions in 
the realm of consumer graphics and audio hardware, 
respectively. And Digidesign's Pro Tools, the perennial 
favorite of sound designers and composers, was inducted 
into the Game Developer Hall of Fame. 

A Multitude of Thanks 

I'd be remiss if I didn't take this opportunity to offer 
heartfelt thanks to our distinguished panel of judges 
thisyear. These individuals, all of whom work in the 
industry, made these awards possible. Wecouldn't have 
done it without them. They are: Andrew Boyd, Chuck Carr, 
JeanneCollins, Ron Fosner, Mel Guymon, MarkHaigh- 
Hutchinson, Tom Hays, Jim Hedges, Stefan Henry-Biskup, 
Rob Hubbard, Mike Kelleghan, Jeff Lander, Spencer Lindsay, 
Dominic Perricone, Wallace Poulter, Greg Pyros, Todd 
Siechen, Paul Steed, Dan Teven, Ben Waggoner, Rob Wyatt, 
and Hal stead York. 
Now onto the winners... 
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Hall of Fame 
Award 




Pro Tools 

Digidesign 

Every so often, I come across an article about a game 
development team that did a hit on the cheap, and the 
team'ssound person did all of thesound effects using a $200 
sound card and a stereo sample editor. I then chuckle about 
how tough life was before I got set up with Digidesign's Pro 
Tools. 

For those who are required to create large quantities of 
professional-quality audio for A-list games day in day out, it 
makes good economic sense to spend a few thousand dol- 
lars on some good gear. At the majority of large game devel- 
opment houses, not to mention film and TV sound design 
shops, this gear includes Pro Tools. 

Pro Tools debuted as a successor to Sound Tools, a highly 




successful stereo hard disk 
recording system that used 
Sound Designer II as its soft- 
ware front end. Pro Tools 
added the ability to use four 
tracks (expandable to 16), as 
well as non-destructive edit- 



ing features such as fades. For a few years. Pro Tools with 
Sound Designer II comprised a power pair, letting users easily 
open data in both programs, apply plug-ins, edit to the sam- 
ple level, and do multi-track mixes with impeccable quality. 

Today's Pro Tools 24 M ix seamlessly scales from massively 
zooming in on a waveform to nail a click, out to a 64-track 
mixing session with gobs of in-line DSP power. It's great for 
building and revising complex game play effects. Pro Tools 
has earned itsplacein theHall of Fame by setting the stan- 
dard by which its competition is judged, and continuing to 
raise that standard each year since its introduction. 

Pro Tools joins past Hall of Fame inductees Watcom 
C/C-hh Borland C-H-, The M iles Sound System, Bounds- 
Checker, SoftlCE, 3D Studio 1.0, Deluxe Paint, DeBabelizer, 
Sound Forge 1.0, Cool Edit 1.0, Cakewalk Pro for Windows, 
SoundBlaster 1.0, The Mythical Man Month, and Computer 
Graphics: Principles and Practice. — Tom Hays 
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Programming 
Libraries, APIs, Engines 




Programming 
utilities 




Netlmmerse 

Numerical Design Ltd. 




Rendering in 3D is hot right now. To get a head start, 
many companies are licensing game engines for their 
development. However, many engines are too general or 
too specific to a game genre and may not be well -suited to 
an individual project. 

Numerical Design Ltd. 's Netlmmerse is a true general 
ren deri n g seen eAPI.lt takes u p wh ere pu re ren deri n g 
libraries such asDirectSD and OpenGL leave off. 

Netlmmerse provides scene management, 

collision detection, animation support, 
and many other features that make render- 
ing a game environment possible. Many 
such libraries could be so general that they 
would not be cutting-edge. However, NDL 
has a strong technical background and has 
built in many features that developers real- 
ly want these days: particle systems, skele- 

tal deformation of skinned characters, continuous LOD, 
and many others. There is also strong integration and sup- 
port for 3D Studio M ax. 

The engine supports OpenGL, Glide, and DirectBD mak- 
ing it easy to integrate into most current 3D projects. 
Another wise choice NDL has made is to include full source 
code and well -documented API reference manual s to 
licensees. This allows developers to modify portions of the 
engine easily to their own project, as well as debug strange 
behavior. This open attitude is very welcome and gives NDL 
a clear advantage over other game libraries. 

For the game development community at large, perhaps 
Netlmmerse's greatest advantage is that it allows both new 
devel pers an d t h ose w i sh i n g to j u m p-start th ei r 3 D tech - 
nology easy access to the cutting edge. — jeff Lander 



MediaStation 3.o.io 

NxN Digital Entertainment 

igger teams, longer development cycles, more con- 
tent, more interdependencies: these trends make it 
ever harder for us to track the state of our projects. Kudos 
to NxN for recognizing an emerging product niche, and 
delivering a "complexity management" tool that's designed 
specifically for game developers. 

It's hard to describe MediaStation adequately because it 
does so many things, and because it's readily customizable. 
It's a build environment. It's a version con- 
trol system, optimized for media asset pro- 
duction. It's a multi-user project tracking 
database. It's a dessert topping. 
!• Thebest thing about MediaStation isthat 
I ^ M ^^^ really understands the problems of 
LkI ^ modern game development. MediaStation 
19 9 9 gives your whole development effort struc- 

ture without becoming intrusive. You can 

integrate your other tools into its IDE, or you can use the 
MediaStation SDK to givea custom tool (likea level editor) 
a more powerful back end. You can store meta-information 
with assets, which helps when you need to create localized 
versions, demos, and versions for multiple platforms from 
the same pool of files. And of course, you can ensure that 
everyone has access to the right version of a file at all 
times, that only authorized persons can modify files, and 
that the right files end up on the master CD. 

The user interface is well thought out, the product is 
scrupulously documented, and it's easy to get up and run- 
ning. It'shard for me to imagine a game development team 
that wouldn't benefit from using MediaStation — I've 
worked on several that would have killed for it. 

— Dan Teven 



Fl N ALISTS: Fastgraph 5.0 for Windows (Ted Gruber Software); 
Motivate (The Motion Factory); RTIME 3.0 (RTIME) 



FINALISTS: Code Co-Op 2.0 (Reliable Software); iPEAK Graphics 
Performance Toolliit (Intel); Observation Architecture (Intel); 
VTune 3.0 (Intel) 
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Programming 
Environments 



Production 
utilities 




SN64 PRO-DG 1,0,0,4 

SN Systems 

Sometimes, the best in novations come from a system's 
interface. Asa wholetheSN64 PRO-DG system is 
great, and now by adding a visual interface, SN Systems has 
really simplified the developer's working process. The inter- 
face's visual approach allows you to drag and drop items, 
simplifies setting up project files, removes some of the intri- 
cacies of makefiles, and makes it easier to add files to exist- 
ing projects, along with many other benefits. This is espe- 
cially helpful to new developers unfamiliar 

with the make process. 

D esp i te t h ese si m p I i fi cat i n s, t h e i n t erf ace 
remai ns customizable enough for experi- 
enced programmers. Built-in scripting, 
macros, and redefin able keyboard shortcuts 
allow programmers to extend its functionali- 
ty. Another great aspect of the SN64 PRO-DG 
is its abi I ity to update directly over the 



FileMaker Pro 4.1 

FileMaker 




internet. Thetext editor isalso oneof the features which 
makes theSN 64 such atruly integrated environment — you 
really never need to leave the program. 

Although there was no manual, the in-program help was 
informative. The system's approach isgeneral enough to 
support any future target platform, and for this it's to be 
commended (although this also means it can't handle some 
of the more subtle aspects of a specific development envi- 
ronment). It costs a little more than other development sys- 
tems, but its feature set exceeds that of al I of its competi- 
tors. 

In short, theSN64 PRO-DG is pretty much essential if 
you're doi ng N 64 development. I suspect other console 
development might be going forward, so keep an eye on SN 
Systems. — Mark Haigh-Hutchinson 



Producing games is hard work. There are so many 
things to track: graphics, sound files, bugs, hours, and 
more. Can game developers find one low-cost database 
package to do it all? FileMaker Inc. (formerly Claris) has 
provided the answer with FileMaker Pro 4.1. It comes com- 
plete with tools to develop entry screens, reports, and even 
theability to publish them on the web. 
The interface is so intuitive and online help is so exten- 

sive, most computer literate people can 

develop a usable database structure without 
ever reading the manual. What is particularly 
amazing is how many of FileM aker's built-in 
• • features could only be achieved by writing 

I ^ M ^^^^ extensive scripts with other database prod- 
LkI ^ ^ ucts, such as theability to set up a screen 
\9 9 9 where data entry or modification of each 

field is dependent upon the user's login 

name. 

Every area of production has something they need to 
track in a database. With relative ease, each group can easi- 
ly build their own data tracking tools to suit their needs 
and publish that data to the company intranet to share 
with other departments. Si nee game products vary greatly, 
standard bug reporting systems are rarely robust enough to 
handlegames. FileMaker istheanswer. A bug tracking tool 
and reporting system can be built on-the-fly in I ess than a 
day, and can last the whole project long. 

FileMaker works for all game production users because it 
istruly cross- platform compatible. Network- stored databas- 
es can be accessed by both Macintosh and Windows 
clients. FileMaker Inc. also offers exceptional multi-license 
discounts. — jeanneCollins 



FINALISTS: CodeWarrior Pro 4.0 (Metrowerks); Intel C/C++ 
Compller 3.0 (Intel); Visual C++ 6.0 (Microsoft) 



FINALISTS: MSDN (Microsoft); Norton Ghost (Symantec); 
Project 98 (Microsoft) 
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Image Editing & 
Manipulation 



3D Modeling & 
Animation Environments 




DarkTree Textures 

Darkling Simulations 



Maya 

AliaslWavefront 




arkTree Textures takes the power of procedural tex- 
tures and lays it out in an easy-to-use and highly 
flexible format. Procedural sh ad ers have always been a 
very useful tool for rendered images, providing subtle con- 
trol and endless variation for surfaces. DarkTree also pro- 
vides toolsto make textures that do tile, a big plusfor 
games use. 

The layout of the tree construction is 
easy to handle. All of the modules 
arranged on the left of the screen can be 
dragged out to the schematic-like con- 
struction area. The range of the modules 
provided greatly exceeds that found in 
most 3D packages. M any of the modules 
provide unique methods for combining 

the other elements. The ability to seethe 

shader plainly not only makes the tool easy to use but also 
makes the reusabi I ity of complex trees as the basis for oth- 
ers much more feasible. Your tree is never static. If you 
decide you want to add anew module in between some 
already laid out, it's easy to move components around. A 
wide array of options allows the user to visualize the tree 
in useful ways, and a large selection of useful samples is 
also included. The package's library tool is very handy for 
keeping track of your creations. 

Dragging files directly to therenderer, the ease of nam- 
ing files, and support for batch rendering all make the 
product user-friendly and well thought out. There's even a 
plug-in version availablefor 3D Studio Max, Animation 
Master, and Lightwave. 



Stefan Henry-Biskup 



■ have used many different 3D packages over the years, 
but few have had the effect on me that Maya has in such 
a short time. Upon first glance at the Maya toolset and its 
capabilities, it's easy to feel overwhelmed at the variety and 
complexity of tools at your disposal, but I have yet to see 
another application deliver such a wide range of functional- 
ity in such a usable package. 

The first thing that becomes apparent in 
Maya is its innovative object manipulation 
paradigm. After only a few moments with it, I 
wondered why every 3D program doesn't use 
• • the same or a similar technique. The ability 

I fk" to work easily in a single perspective view 

Li\l ^ while maintaining thecontrol to rotate, scale, 
19 9 9 and transform in any locked axis without 

using a hot key is wonderful. 

M ay a al so h as a f an tasti c custom i zabi e i n terface th at i s 
easily tunable to the individual artist's needs. These simple 
revolutionary features will save you a great deal of produc- 
tion time. Maya still has a few rough edges, but the features 
I have struggled with in other programs such as inverse 
kinematics, constraints, skinning, deformations, and 
NURBS are all very easy to use and implement with Maya — 
and they work. 

It should be noted that all this great functionality comes 
to us in Maya's infant first version. Version 2.0 promises 
many refinements, improvements, and increased usability 
to an already strong package. All these wonderful features 
combined with the product's recent price decrease make 
M aya th e cl ear wi n n er. 

— Todd Siechen 



FINALISTS: KnockOuti.o(Ultimatte); Painter 5.5 
(MetaCreations); Photoshop 5.0 (Adobe) 
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Fl N ALISTS: 3D Studio MAX 2.5 (Kinetix); Lightwave 3D 5.6 
(NewTeIc); Rhinoceros (Robert McNeel & Associates); 
Softimagel3D 3.8 SPi (Softimage) 



3D Modeling & 
Animation Plug-Ins 



Video Editing & 
Compositing 




Surface Tools 

Digimation 




Asadigital artist, I've been modeling for years in poly- 
gons and have tried many different ways of manipulat- 
ing them in a fluid and organic way. I've tried patch model- 
ing, NURBS packages, and lofting. All of these methods have 
their advantages, but Surf ace Too Is gives me the most freedom 
to work with for the price. 

With Surface Tools, Digimation offers an excellent modifi- 
cation to theexisting patch topology tools 

already in 3D Studio Max. The once unattain- 
able (or at least very difficult) organic surface is 
now a breeze to create and modify. By creating 
Bezier splines to define the basic shape and 
form of a model, a modeler can quickly gener- 
ate very tunable patch sets that can then be 
converted to a number of different resolutions. 

It's I i ke model i ng with j ust the edges of patch- 

es. Th e I earn i n g cu rve i s rel ati vel y sh al I o w, an d on ce you get 
the hang of it. Surface Tools is very easy to move around in. 
Depending on how you set your work up, the quick sketch 
feel of Surface Too I sal lows you to make a lot of iterations 
while always letting you go back to a good old version. I have 
used Surface Too Is extensively in modeling everything from 
cars to mountains. 

W h i I e I was at Atari , my team was respon si bl e f or gen erat- 
ing the new cars for Rush 2049. 1 had the art team use Surface 
Tools because we could get excellent control over the smooth 
surfaces. We were also able to generate both high-resolution 
models for cutscenes and then just crank down the resolution 
f or th e real -ti me versi on s. 

All in all, SurfaceToolsisoneof the coolest tools in my 
arsenal . — Spencer Li ndsay 



Ulti matte Software 

Ultimatte Corp. 

he Ultimatte chroma-compositing workflow has 
P existed in the post-production arena for many years. 
Indeed, Ultimatte blue and green are colors recognized 
throughout the industry. With the Blue ICE-accelerated 
version of their After Effects plug-in, Ultimatte brings the 
power and speed of a multi-million dollar post-produc- 
tion environment into the reach of small, independent 

shops. 

The Ultimatte pi ug-in's interface is 
extremely simple and intuitive for trained 
After Effects users. The manual is extremely 
• • informative, but even without it every- 

I ^ m S^^^ thing isjust where you think it should be. 
LkI L>' ^ The more advanced features are easy to 

X9 9 9 access for advanced users, and easy to hide 
for beginners. Absolutely beautiful chroma- 
keying is only a few mouse-clicks away. Matte clean-up is 
more difficult, but even a newcomer to compositing can 
easily get results far better than they could with just 
about any other tool on the market, no matter what the 
price. 

Ultimatte has delivered theholy grail: an extremely 
useful and rock-solid piece of software that extends the 
capabilities and professionalism of anyone who uses it. 
It's not so much a revolutionary product, but ICE'd 
Ultimatte is robust, thoughtful, and mature. If you need 
to get professional quality compositing done today, get 
yourself After Effects, a Blue ICE card, and the Ultimatte 
plug-in. It offers that greatest of gifts — the chance to go 
home early and do it with a clear conscience. 

- Halstead York 



FINALISTS: Character Studio 2 (Kintetix); MetaReyes 4.0 (REM 
infografka); ProMotion (LambSoft); Surface Suite (Sven 
Technologies) 



FINALISTS: Automaslier AE2.0 (Automedia); effect* (Discreet 
Logic); ICEfx2 for After Effects (integrated Computing Engines); 
MediaStudio Pro 5.2 (Ulead Systems) 
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Wildcat 4000 

Intergraph 




The Wildcat 4000 isa great scalable video card for high- 
end graphic systems. Up to four cards and a geometry 
accelerator can be used in a single machine. If required, 
each card can driveaseparatemonitoror work in unison 
with the others. With four cards, the memory limit is 
256M B of frame buffer and 1GB of texture memory. For the 
first time on the PC, the wholeOpenGL pipeline is imple- 
mented in hardware. If your application usesOpenGL's 

advanced features, you'll be pleased to know 

that anti-aliasing, stencil buffers, overlay 
buffers and OpenGL accumulation buffers 
are all fully supported in hardware. Exten- 
sions include volumetric fog, volumetric 
lighting and 3D textures. 

The card has a full complement of drivers, 
supporting OpenGL, RenderGL, DirectDraw 

and Direct3D in Windows NT and 95. 1 ran 

the GL conformance tests which all passed, and then tried 
some real applications (including 3D Studio Max and 
Maya), and they all performed flawlessly. Quake 2 also ran 
with no problems. 

The downsides are its maximum resolution of 1280x1024 
and the texture fill rate of 90 million pixels with all features 
enabled — which was apparent when playing Quake at 
maximum resolution. Thefill rate may not bean issuefor 
the you, however, as most things are modeled and animat- 
ed in wire-frame or flat shaded; geometry processing is far 
more important. 

User control is supported via an applet to set up multiple 
cards and monitors. Intergraph usually provides regular dri- 
ver updates and their tech support is good. The base price 
for the 48M B version (16M B frame buffer and 32M B of tex- 
tures) is $2995, which is significantly cheaper than the 
competition. — RobWyatt 



Viper V550 

Diamond Multimedia Systems 

Apparently Diamond has some great karma. J ust as its 
once-close ally, 3dfx, shifted strategies and became 
Diamond's arch nemesis, Nvidia showed up on Diamond's 
doorstep with theRivaTNT. How's that for timing? 

Th e Ri va TN T ch i p was th e bi ggest ad van cemen t i n con - 
sumer3D hardware last year, beating out the old champ, 
Voodoo2. Combined with the fantastic TNT is Diamond's 
know-how in the card business. Simply put. Diamond 

knows how to take chips and turn them into 

excellent consumer solutions. Last year we 
recognized Diamond for itsfine work with its 
M onster 3D card, and it earned the Front 
• • Line Award again thisyear for the Viper 

V550. Available in both AGP 2X and PCI fla- 
LkI ^ ^ vors. Diamond's Viper V550 features a long 

19 9 9 list of features that made for great gameplay- 
ing last year: full screen anti-aliasing, a trian- 
gle set-up engine, anisotropic filtering, bump mapping, a 
24-bit Z-buffer, an 8-bit stencil buffer, M PEG, TV output, 
and 16M B of 125M Hz SDRAM . The 2D acceleration is excel- 
lent as well, which means no sacrifices once you jump out 
from game land to take care of some business. 

I've always had smooth setup experiences with Diamond 
hardware, and the Viper V550 is no exception. The 3D con- 
trol panel and thedesktop utilities that come with thecard 
are great. 

Thecard outperformed other TNT-based cards in synthet- 
ic benchmarks like Winbench 98 and 3D Winbench 98, and 
certainly held its own in real -wo rid tests too. It was definite- 
ly a hardware highlight in 1998, and I look forward to what 
Diamond and Nvidia will bring us this year with theforth- 
comingTNT2-based Viper V770. — Alex Dunne 



FINALISTS: Gloria-XXL (ELSA); Oxygen GMX(3Dlabs); TITAN II 
(MaxVlslon) 



FINALISTS: AU-ln-Wonder Pro AGP (ATI Technologies); 
MiUennlum G200 (Matrox Graphics); Monster 3DII (Diamond 
Multimedia Systems); Terminator BEAST Supercharged 
(Hercules Computer Technology) 
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Professional 
Sound Hardware 



Consumer 
Sound Cards 




MOTU 2408 


Sound Blaster Live! 


Mark of the Unicorn 


Creative Labs 



Th e M ark Of th e U n i CO rn ( M OTU ) 2408 h ard d i sk 
recording system in dudes a PCI card, a single rack- 
space I/O unit, a 12-foot cable, software drivers for both 
Windows and MacOS, and a complete audio workstation 
software package for MacOS called Audio Desk. It has 
eight analog inputs/outputs with 20-bit converters, 24 
channelsof AD AT optical input/output, 24 channels of 
TDIF input/output and stereo S/PDIF in/out (with an extra 

stereo out). It provides word clock, ADAT 

Sync and Digital Timepiece Control Track 
sync, which achieves sample-accurate dig- 
ital transfers between digital tape decks 
and the computer. 

The MOTU 2408 supports stand-alone 
format conversion so you can transfer any 
format (ADAT, TDI F, or analog) to any 

other, up to 24 channels at a time. The 

24-bit internal data path of the MOTU 2408 supports 24- 
bit recording via 24-bit hardware (mixer, preamp, FX 
processor, or other device) connected digitally. So what's 
the bottom line? It sounds great! I'm using it with my 
400M Hz PC and a Panasonic DA7 with two ADAT cards 
connected to the 2408 and getting 16 channelsof pristine 
digital audio. I'm also using the analog outs of the 2408 
going to the first eight channels of the DA7. All of my 
software applications such as Cakewalk Pro 8, Acid, Sound 
Forge 4.5, and Cool Edit Pro 1.1 support it. My only com- 
plaint is that it doesn't have Windows NT drivers yet. 

With its excellent sound quality, features, and list price 
of $999, the 2408 is a solid choice for people using PCs or 
Macintoshes for professional audio applications. 




Chuck Carr 



FINALISTS: DSP Factory (Yamaha); Layla (Event Electronics); 
Paris (Ensoniq); Pro T00ISI24 MIX (Digidesign) 



CreativeLabs's Sound Blaster Live! is the definitive 
sound card for game players. Notable features include 
32 channelsof DirectSound3D hardware acceleration, 
downloadable sounds (DLS) and environmental audio 
extensions (EAX) for reverb and echo effects. The card uses 
PCI bus mastering and the advanced EMUIOKI, a lOOOMIPS 
digital signal processor, which delivers audiophile-quality 
sound. 

For games using DirectX, the card performs 

very well, with very little impact on things 
such as frame rate and graphics. Thisisvery 
important, as some other cards take up a lot 
!• of the host CPU when doing DirectSoundBD. 

JMM/fJ^ The card boasts a very good feature set con - 
Lki LB) S sidering the low cost ($99 for the value card). 
19 9 9 It supports mu I ti -speaker output as well as 

EAX, which adds different reverbsand echoes 

according to the location or environment that the game is 
in.Thiscan be very effective in first-person games such as 
Half-Life or Unreal. The standard card ($199) has digital 
output (SPDIF) and a daughter card containing standard 
MIDI ports. 

The installation issimple, thecard isreliable, and it 
comes with a good manual. Thecard also comes with an 
extremely useful software bun die, including a good audio 
customization utility. The speaker configuration application 
is the most useful, allowing the user to select two or four 
speakers or headphones. 

C reat i ve p I an s on f utu re d ri ver en h an cemen ts f or th e 
Sound Blaster Live!, so it can support over 70 voices of 
DirectSound3D and new features such asAC-3 Dolby Digital 
decoding and eight-speaker support. — Rob Hubbard 



FINALISTS: EMU8710 PS (E-Mu Systems); Monster Sound 
MMX300 (Diamond Multimedia Systems); Waveforce 192 Digital 
(Yamaha) 



http://w WW .gdmag.com 



JUNE 1999 GAME DEVELOPER 



FRONT LINE AWARDS 



Audio 
Recording & Editing 




Audio 
Composition 




Peak 2.0 

Berkeley Integrated Audio Software 



The Macintosh has long been considered the standard 
platform for professional audio development. With 
products such as Pro Too Is (this year's Hal I of Fame inductee) 
as well as excel lent sequencers and librarians, robust MIDI 
and audio support, QuickTime, and so on, Macintosh has 
been the platform of choice for anyone serious about audio 
production. Yet in all this, basic two-track editing seemed to 

get lost. Innovation was absent from the slow, 

u n stabi e app I i cat i on s aval I abl e. Fi I e format su p- 
port was inconsistent, while interfaces were 
unattractive and unintuitive. 

Well, there's finally a really good, general- 
purpose two-track audio editor on the 
Macintosh. Peak 2.0 is miles ahead of its prede- 
cessors in terms of features and interface, and 

significantly betterthan its other Macintosh- 

based competitors, too. It's easy to use, reasonably quick, 
sounds great, and integrates with surprising ease into a pro- 
fessional audio production system. 

It has all the right features: n on -destructive editing, a long 
list of supported formats, batch processing, integrated 
QuickTime video support, good-sounding standard DSP 
functions, and sampler support. Peak offers some really cool 
additions, too: fun effects such as "convolve" and "phase 
vocoder," handy real -time application of file-based Premiere 
plug-ins, and best of all, theability to handleTDM and 
Audiosuite plug-ins. 

But what really makes Peak stand out is the fact that all 
thisquality and functionality arenow availableon theMac- 
intosh, able to live on the same machine with all the other 
great tools you're probably already using. — Andrew Boyd 



ACID PRO 

Sonic Foundry 




Jg^ cid isarguably the most innovative digital audio sof t- 

wareto come along in years. If you use digital audio 
loops, you want Acid. It's that simple. 

Unlikeother programs that can changea loop'stempo 
by changing its pitch. Acid keeps the original pitch when 
changing tempos. Acid does an almost magical job when 
speeding up or slowing down tempos, and it works best 

when speeding up a loop from its original 

tempo. 

Although you can record individual 
tracks with Acid, I liken songwriting with 
!• Acid to drum pattern creation on a drum 

jMJUaJ^ machine. Create the parts of a song you're 
LkI LJ ^ working on (I ike your drums, guitar parts, 
19 9 9 and bass lines) as two-,four- or eight-bar 

loops. Then add the loops in Acid to build 

thesong. It's also great for experimenting with different 
arrangements by changing the chorus and verses to dif- 
ferent places in a tune. 

Doing remixes with Acid is amazing. If you want to mix 
your tune and you have a multi-track audio card or hard- 
ware box. Acid lets you assign your tracks to whatever out- 
put you want. If you want to add some real-time effects or 
compression to your tracks, go ahead — with the support 
of DirectX plug-ins it's a no-brainer. Sonic Foundry's 
Virtual MIDI Router (VM R) is the perfect "missing link" for 
synching Acid with a software sequencer. 

I use Cakewalk for all my MIDI and non-loop-based 
audio and Acid for the loop-based digital audio. Perhaps 
this sounds like a dream scenario, but believe me, the 
dreamisreal. — ChuckCarr 



FI N ALISTS: Pro Tools 4.3 (Digidesign); SonicWORX (Prosoniq 
Products Software); Sound Forge 4.5 (Sonic Foundry) 
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FINALISTS: Cubase VST/24 4.0 (Steinberg); Logic Audio 
(Emagic); Pro Audio Deluxe 8 (Caliewalk); Studio Vision 4.1 
(Opcode Systems) 
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Quakes: Arena is one of the first games to tal<e advantage 
of curved surfaces in a real-time 3D setting. 



emember Quake? Back when it was first 



released, consumer-level 3D accelera- 



tion was nearly unheard of, and id's 



software renderer scaled in speed with 



the clock speed of your Pentium 
processor. 



During thefew years since then, though, our market has 
reached a point of stratification with n on -accelerated 
Pentium "Classic" machines on the low end and the latest 
and greatest pixel crunchers on the high end. The range is 
enormous. As game developers, it's important to support 
high-end consumers, and yet we'd prefer not to abandon the 
low-end players. From thisdesire wasa new industry trend 
born: scalable geometry. 



Scalable Geometry 



Scalable geometry is any kind of geometry that can be 
adapted to run either faster with decreased visual quality 
or slower with increased visual quality. There are a number of 
ways of doing this, so we'll briefly cover the mo re popular 
methods. 

Oneoftheearliest methods used in games to scale geometry 
involved hand-generated le/el-of-detail models. You can see this 
princi pleat work in games I ikeBATTLEZON Band Grand Prix Legends 
In thecaseof aracecar, artistscreatea very high-detail model of the 
car, then a lower-detail model, and then continuedown to a very 
low-detail model. Then, at run time, factors I ike the speed of the 
machineandthedistanceofthecartotheviewerdetemninewhich 
model you useeach frame Oneof thebenefitsthat hand-tuned 
LCD modelshaveover other approachesisthatthemodelscan have 
more actual polygonal detail atthehigher le/els^ since they'recreat- 
ed by hand. There are many drawbacks, though. For instance, the 
SA/itch from one model to another can manifest itself as an abrupt 
visual "popping", and can therefore be distracting to theviewer. A 
solution to thisisto increase thenumber of LCD models, but this 
exposes another drawback: it takes a lot of an artist's time to make 
SB/eral versionsofe/ery object. 

Another method of implementing scalablegeometry isin using 
dynamic mesh reduction techniques Shiny's upcoming title, 
M Esa AH , reportedl y uses a tech n i que I i ke th i s for th ei r ch aracter an i - 
mation system. Theideahereisthat you storeonehigh-detail ver- 



W hen Brian's not coding for CogniToy or sleeping through 
classes, he's writing up crazy stuff like this. Keep him busy by 
writing to him at bri a n_sh a rp(g)cogn itoy.com with questions or 
comments, or else he might find the time to write again. Don't 
say we didn't warn you. 
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CURVED SURFACES 



FIGURES 1 AND 2. The top figure is 
a Hermite curve. Tangent vectors are 
magenta, end points are red, and the 
curve itself is blue. The second figure 
is a cubic Bezier curve. Its control 
points are red, and the curve is blue. 




son of a model. Then, based on thedistance 
of the model from the viewer and the 
desired framerate, you usesomekind of 
detail reduction algorithm to generatean 
appropriate mesh. There area number of 
ways to perform the detail reduction; if the 
high-detail model isstored as a polygon 
mesh,algorithmslikethequadricerror met- 
rics described by Garland and Heckbert are 
perfectforthetask. Theadvantagesto 
dynamic mesh reduction are that many of 
thetechniquescan bevery fast with some 
precalculation, and it can produce very 
good-looking results There are, again, a 
number of drawbacks It can betrickytoget 
texture coordinates to reduce with the mesh 
without makingthetexture slide around on 
the model. Also, algorithmically reducing a 
model from 10,000 polygonsto 50 polygons 
sti 1 1 gen eral I y won 't I ook as good as a 50- 
polygon model hand-crafted by an artist. 

Curved Surfaces 

Thefinal method we'll mention, 
th en , i s th e top i c of th i s arti cl e. 
Curved surfaces are one of the most 
popu I ar ways of i mpl emen ti n g seal abl e 
geometry. There is a good reason for 
that, too; in games we've seen them in, 
they look fantastic. Un real's characters 
looked smooth whether they were a 



hundred yards away, or coming down 
on top of you. Quake 3: Arena screen- 
shots show organic levels with stunning 
smooth, curved wall sand tubes. There 
area number of benefits to using curved 
surfaces. Implementations can bevery 
fast, and thespace required to store the 
curved surfaces is generally much small- 
er than thespace required to store either 
a number of LOD modelsor a very high- 
detail model. 

The downside of curves and curved 
su rf aces i s t h at t h ey are perh aps t h e 
most difficult of the three methods to 
learn and understand. There's a lot of 
reference material out there, but a lot of 
it is not easy reading, even if you know 
the material and arejust using the 
books for reference. Therefore, in this 
article, we'll look at the basics of curves 
and curved surfaces. We'll cover the 
concept of the basic polynomial curve, 
and then onto two example curve repre- 
sentations Hermite curves and Bezier 
curves. From there, we'll move onto sur- 
faces, CO veri n g th e Bezi er patch . I n th i s 
article, we'll take the most straightfor- 
ward approach possible to rendering the 
curves and patches. Whilethisdoes 
mean that our implementations will be 
very slow, they will hopefully be more 
legiblefor it. Next month, we'll contin- 
ue our examination of patches by delv- 
ing into optimization techniques to 
make them truly useful. 

Remedial Curve Concepts 

Just to be absol utely sure we al I start 
off on the same wavelength, we'll 
start by reviewing some of the basic 
math principles that weneed asafoun- 
dation for working with curves and 
curved surfaces. Feel free to skip this sec- 
tion if this is remedial. 

At its core, any of the curves we'll dis- 
cuss can be represented as a parametric 
polynomial function. Following con- 
vention, we'll use the parameter u. Our 
curves will look something I ike this: 

X(U) = CqU^ + c^u^ + C2U + C3 

y(u) = C4U^ + C5U^ + C6U + C7 
z(u) = C8U^ + C9u2 + CioU + Cii 
f(u) = (x(u),y(u),z(u)) 

Generally, we'll refer to f(u), which is 
the3D point on thecurveat u. Now, as 
long as at least one of Cq, C4, and Cg are 
non-zero, the curve will be a cubic 



curve, and cubic curves are the ones 
we're most i nterested i n . After al I , si nee 
we'd I ike to keep computation to a min- 
imum, we'd I ike to use the lowest- 
degree cu rve possi bl e (si n ce a h i gh er 
degree requires more multiplication 
every time it's evaluated). So, we might 
try using a zero-degree curve (which 
would be fast to compute). But a zero- 
degree curve is simply a point, which 
doesn't do us too much good. 

Moving on, a one-dimensional curve 
is simply a line. It's pretty clear that 
lines are insufficient for our purposes. 
So, we move on to quadratic curves. 
These are parabolas, which might seem 
sufficient for representing curves and 
curved surfaces. Unfortunately, second- 
degree curves will always lie in a plane, 
and we're working in three dimensions, 
so it would be better to have a space 
curve, a curve that isn't confined to two 
dimensions or less. Therefore, our cubic 
cu rve i s t h e cu rve of ch o i ce. 



Representations 



So all a programmer needs to do is 
code up a quick tool for the artists 
consisting of a view window and four 
text entry boxes for them to type in the 
coefficients of curves, right? Of course 
not — artists demand flexibile, intu- 
itive tools, and it'sclear that creating 
curves by typing in coefficients lacks 
that certain ease-of-use factor for most 
of us Therefore, we need another rep- 
resentation for the curve that makes 
creation and manipulation more intu- 
itive. We'll touch on two such repre- 
sentation s, th e H erm i te cu rve an d 
Bezier curve. 

Th e H erm i te cu rve we cover both 
because it's fairly common, but also 
because it doesn't require any specialized 
formulae to understand it. Then, as 
Bezier curves are somewhat more versa- 
tile, we'll move on to them. While we 
won't discuss it here, converting from 
Bezier curves to Hermite curves and vice 
versa is very straightforward and is 
explained in the references at the end of 
the article. 

There are plenty of other curve repre- 
sentations that we aren't going to touch 
upon. Notably, we are not going to cover 
B-Splines or that family (including the 
pervasive NURBS), of which Bezier 
curvesaresimply a special case. I chose 
theHermiteand Bezier curve models as 
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LISTING 1 . Code to generate a cubic parametric equation from a Hermite 
curve's endpoints and tangents. 



void genCubicFunctionO 
{ 

// Do this so we can treat each endpoint and tangent vector as a separate array, 
float* pO = points; 
float* pi = points + 3; 
float* vO = tangents; 
float* vl = tangents + 3; 

// Do this so we can treat each vector coefficient of the function as a separate array 
float* a = functionCoeffs; 
float* b = functionCoeffs + 3 
float* c = functionCoeffs + 6 
float* d = functionCoeffs + 9 
// Now, generate each coefficient from the endpoints, tangents, and the predefined 
// basis functions. 

// Note that we loop once each for the x, y, and z components of the vector function. 

for (int lev = 0; lev < 3; lcv++) 

{ 

// a = 2p0 - 2pl + vO + vl 

a[ lev ] = (pO[ lev ] + pO[ lev ]) - (pl[ lev ] + pl[ lev ]) + vO[ lev ] + 

vl[ lev ]; 
// b = -3p0 + 3pl - 2v0 - vl 

b[ lev ] = - (pO[ lev ] + pO[ lev ] + pO[ lev ]) + (pl[ lev ] + pl[ lev ] + 
pl[ lev ]) - (vO[ lev ] + vO[ lev ]) - vl[ lev ]; 

// e = vO 

c[ lev ] = vO[ lev ] ; 
// d = pO 

d[ lev ] = pO[ lev ]; 

} 



} 



a good starting point, because they can 
be represented and understood with a 
f ai r degree of ease. O n ce you h ave a fi rm 
grasp on Bezier curves, picking up oneof 
the references at the end of this article 
and learning more about other curve 
models is much easier. 



Hermite Curves 

A Hermite curve is a cubic curve 
described by its endpoints Pq and 
and thetangent vectors at the end- 
points, Vq and You can see in Figure 1 
what an examplecurve looks like. 




The question, then, is how we get the 
cubicequation from thepointsand vec- 
tors. Hermite curves are nice this way, as 
the derivation of the cubic is possible 
with justa littlecalculus. Let'ssay our 
cubicequation is 

f (u) = au^ + bu^ + cu + d 

Note that f(u), a, b, c, and d are vec- 
tors. Then, we have that: 

f'(u) = 3au^ + 2bu + c 

Then, we can express the endpoints as 
f(0) and f(l), and the tangents as f'(0) 
andf'(l). 



Po=f(0) = d 

p^ = f(l) = a + b + c + d 

Vo = f'(0) = c 

v, = f '(l) = 3a + 2b + c 

Solving now for a, b, c, and d, we get: 
a = 2po-2pi+Vo+Vi 
b = -3po + 3pi-2Vo-Vi 



d= Po 



Eq.l 



Then we'll solvefor what are called the 
" basi s f un cti on s. " Th e basi s f u n cti on s 
are simply functions of u that determine 
the contri bution of the endpoints and 
tangents along the curve. So, for 
instance, the basis function that corre- 
sponds to Pq determines how much Pq 
contributes to points along the curve. 
Just by rearranging terms once again, we 
h ave th e basi s f u n cti on s. 

Bo=2u^-3u2+l 

Bi = -2u^ + 3u' 

^ -2u' + u 

3 



B2 = u 
B, = 



-u 



Then, we can express the curve as the 
sum of the basis functions times the 
components: 

f(u)=BoPo + BiPi + B2Vo + B3Vi 

This provides us a handy way of 
expressing the curve. Furthermore, basis 
functions become far more important 
when we discuss Bezier curves, and so 
the Hermite curve provides a good intro- 
duction to the idea of a basisfunction. 

So, as we see here, a basisfunction is 
nothing more than a function associat- 
ed with a component of the curve that 



LISTING 2 . Code to evaluate cubic parametric equation at a given value of u. 



// This function simply computes au''3 + bu''2 + cu + d for a 
// specific u and stores the vector result in out. 
void evaluateAt(float u, float* out) 
{ 

//Do this so we can treat each vector coefficient of the function as 
float* a = functionCoeffs; 
float* b = functionCoeffs + 3 



a separate array. 



float* e = functionCoeffs 
float* d = functionCoeffs 



// Note that we use Horner's rule for computing polynomials (which is t 
//we nest the multiplies and adds to minimize the computation we need. 
out[ ] = ( ( ( a[ ] ) * u + b[ ] ) * u + e[ ] ) * u + d[ ]; 
out[ 1 ] = ( ( ( a[ 1 ] ) * u + b[ 1 ] ) * u + c[ 1 ] ) * u + d[ 1 ]; 
out[ 2 ] = ( ( ( a[ 2 ] ) * u + b[ 2 ] ) * u + e[ 2 ] ) * u + d[ 2 ]; 




FIGURE 3. Bezier basis functions for 
a cubic Bezier curve. Each function is 
associated witti a control point. 
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determines thecontribution of that 
component to points along the curve. 

Implementing Hermite Curves 

As h an dy as th e basi s f u n ct i on s are 
for expressing the curve, it's easier 
for our naive implementation just to 
calculate the cubic equation of the 
curve by finding the coefficients using 
Equation 1. The code that does this is 
shown in Listing 1. 

Then, wejust run along the curve by 
starting u at and incrementing it by 
some fixed amount until we reach 1. We 
evaluate the curve at each valueof u, 
save each result as a point on the curve, 
and then render the curve as a line strip. 
The code to evaluate the curve at a 
given valueof u isquitesimpleand is 
shown in Listing 2. 

It's worth noting that even though 
the curve is recalculated fairly slowly 
every frame, the frame rate is still in the 
high hundreds (well, on my Voodoo2 
graphics card, at least). Since we're 
doing nothing but calculating a hun- 
dred or so pointsalong a curve every 
frame, the speed hit as a result of this 
i n eff i ci en cy i s n ot yet apparen t . 



Bezier Curves 

ow that we understand the cubic 
Hermite curve and its implementa- 
tion, we can move on to Bezier curves. 
Whereasa Hermite curve is defined by 
endpoints and tangents, a cubic Bezier 
curve is simply described by four 
ordered control points, Pq, p^, P2, and P3. 
Figure 2 shows an example curve. 

Our problem now is that it's not 
immediately clear how we define the 
curve based on these four poi nts. W ith 
Hermite curves, we could use some basic 
calculus to get a cubic parametric equa- 
tion. But even if we say that Pq and P3 
are the endpoints, the points p^ and P2 
seem to h ave I i tt I e beari n g, an al yt i cal I y , 
on the curve. It's easy enough to say 
that the curve should "bend towards" 
the points, but what does that give us in 
terms of our cubic equation? Here's 
where the importance of our basi s fun c- 
tionscomes in. We need to find a set of 
functions that blend the control points 
together in ways that give us the curve 
that we want. 
To do that, of course, we need to 



definethe properties we'd likethecurve 
to have. We can summarize these with 
threequalities: 

1. We'd I ike the curve to interpolate 
theendpoints. That is, we'd like the 
curve to start at Pq and end at P3. That 
makes curve creation more intuitive. 

2. We'd I ike the control poi nts to 
have local control. That is, we'd I ike the 
curve near a control point to move 
when we move that control point, but 
have the rest of the curve not move as 
much. Again, this gives us better intu- 
itive control when crafting a curve. 

3. We'd I ike the curve to stay within 
theconvex hull ofthecontrol points so 
we can cull against it quickly if we're 
doing visibility culling or hit testing. 

Luckily for us, there exists just such a 
set of functions. These functions are 
called the Bernstein basis functions, and 
are defined as follows: 



B"(u)= . 



u'Cl-u)""' for 0<i <n 



The parenthesized block with then 
and the! is the mathematical phrasing 
of the binomial coefficient normally 
phrased "n choose 1" or "n nCr 1". The 
formula for n choose i is: 

n! 

i!(n-i)! 

If we were considering general Bezier 
curves, we'd have to calculate that. Since 
we're only considering cubic curves, 
though, n =3, and 1 is in the range [0,3]. 
Then, we further note that n choose! is 
the ith element of the nth row of Pascal's 
triangle, and so we have our values, 
{1,3,3,1}. So we can just hard-code that, 
no computation necessary. 

While the Bernstein basis functions 
area littleodd looking at first, they're 
not that bad. To show that they really 
do satisfy our three conditions, we refer 
to Figure 3. Thisisagraph of thecubic 
basis functions. The red curvecorre- 
spondsto Pq, thegreen to p^, the blue to 
P2, and the magenta to P3. They're pretty 



LISTING 3 . Code that tessellates and renders a Bezier curve as an evenly- 
spaced series of line segments. 



void UniformCurveTessellator: :tessellate( const std: : vector< CurvePoint >& controls, 

const std::vector< BasisFunction >& bases ) const 

{ 

// We break the curve into 100 even increments of u. 
int numSteps = 100; 




// We can multiply by this in our loop instead of dividing by (numSteps-1) every time, 
double invTotalSteps = l.Of / (numSteps - 1); 

// Start drawing our curve. 
::glBegin( GL.LINE.STRIP ); 

for ( int step = 0; step < numSteps; step++ ) 
{ 

// Generate the parameter for this step of the curve, 
float u = step * invTotalSteps; 

// This holds the point we're working on as we add control points' contributions to it. 
float curPt[ 3 ] = { 0, 0, }; 

// Generate a point on the curve for this step, 
for ( int pt = 0; pt <= 3 ; pt++ ) 
{ 

// Get the value of this basis function at the current parameter value, 
float basisVal = bases [ pt ]( u ); 

// Add this control point's contribution onto the current point. 
curPt[ ] += controls[ pt ].getX() * basisVal; 
curPtE 1 ] += controlsE pt ].getY() * basisVal; 
curPtE 2 ] += controlsE pt J.getZQ * basisVal; 

} 



} 



// Draw this point. 
::glVertex3fv( curPt ); 



} 



::glEnd(); 
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looking, but what do they mean? Recall 
th at th e basi s f u n cti on s determ 1 n e th e 
contribution of each point over the 
curve. Also, the horizontal axis on that 
graph isu. So, when u iszero, thevalue 
of the basis fun cti on for Pq isl, and all 
the others areO. Therefore, the starting 
point of the curve is: 

lPo + Opi + Op2 + Op3= Po 

Therefore, we have that the curve 
starts at Pq. Looking at the basis func- 
tions, it's obvious that the curve ends 
on P3. Our first condition is satisfied. 

Asfor the local control, we can con- 
vince u rsel ves th at th i s h 1 ds by star- 
ing at the basis functions for long 
enough. It's obvious that Pq and P3 have 
local control, because as we move them, 
the curve moves, and they have very lit- 
tle influence over the rest of the curve. 
We can also see, then, that p^ and P2 
have local control, si nee they have the 
most influence over the curve 1/3 of the 
way and 2/3 of the way along the curve, 
respectively. That means that if we 
moved p^ it would pull thesection 1/3 
of the way along the curve with it, and 
affect the rest of the curve much less. 

Then, we have our final condition: 
the curve must remain within the con- 
vex hull of the control points. With the 
Bernstein basis functions, this is true. 
Theproof, however, is fairly complicat- 
ed, and ends up dragging a bevy of new 
concepts into the fray. For the interest- 
ed, Farin does a reason able job of 
explaining this. It has to do with the 
fact th at th e Bern stei n basi s f u n ct i n s 
are n on negative for u in the range [0,1], 
and also that if you sum up the values 
of al I th e basi s f u n cti on s f or an y val u e 
of u, the result is always 1. 

Then, theformulafor calculating a 
point on our Bezier curve is: 

i=° Eq. 2 

Implementing Bezier Curves 

Our approach to rendering a Bezier 
cu rve i s si m i I ar to t h at f r ren der- 
ing Hermite curves. Wefind a series of 
points along the curve, and render that 
series as a line strip. We'll do it, once 
agai n, by eval uati ng the curve at even 
i n terval sofu.Listing3sh o ws th i s cl ear- 
ly: UniformCurveTessellator: :tessellate takes 
a vector of four control points and a 



LISTING 4 . Code that tessellates and renders a Bezier patch as an evenly- 
spaced grid of triangles. 



void UniformPatchTesseUator: :tessellate( const std::vector< std::vector< CurvePoint > >& 
controls, const std::vector< BasisFunction >& bases ) const 
{ 

// We break the patch into a numSteps x numSteps array of points, 
int numSteps = 10; 

// First, we need to make the basis functions for our normals, which just involves 
// taking the derivative of each basis function. 
std::vector< BasisFunction > bases_deriv( bases ); 
for ( int i = 0; i <= 3; i++ ) 
{ 

bases deriv[ i ] .differentiateO ; 

} 

// Now we generate the points and normals, 
float* verts = new float[ 3 * numSteps * numSteps ]; 
float* norms = new float[ 3 * numSteps * numSteps ]; 
double invTotalSteps = l.Of / (numSteps - 1); 
for ( int stepU = 0; stepU < numSteps; stepU++ ) 
{ 

// Generate the parameter for this step of the curve, 
float u = StepU * invTotalSteps; 
for ( int stepV = 0; stepV < numSteps; stepV++ ) 
{ 

// Generate the parameter for this step of the curve, 
float V = StepV * invTotalSteps; 
// This holds the point we're working on as we add control points' contributions to 
//it. 

float curPt[ 3 ] = { 0, 0, }; 
float curNormE 3 ] = { 0, 0, }; 
float curUTanf 3 ] = { 0, 0, }; 
float curVTanE 3 ] = { 0, 0, }; 
// Generate a point on the curve for this step, 
for ( i = 0; i <= 3; i++ ) 
{ 

for ( j = 0; j <= 3; j++ ) 
{ 

// Get a few basis function values and products thereof that we'll need 
float bu = bases E i ]( u ); 
float bv = bases E j ]( v ); 
float dbu = bases.derivE i ]( u ); 
float dbv = bases.derivE j ]( v ); 
float bu.bv = bu * bv; 
float bu.dbv = bu * dbv; 
float dbu.bv = dbu * bv; 

// Add this control point's contribution onto the current point. 
curPtE ] += controlsE i IE j ].getX() * bu.bv; 
curPtE 1 ] += controlsE i IE j LgetYO * 
curPtE 2 ] += controlsE i IE j ].getZ() * 
// Add this point's contribution to our u 
curUTanE ] += controlsE i IE j ].getX() 
curUTanE 1 ] += controlsE i IE j LgetYQ 
curUTanE 2 ] += controlsE i IE j LgetZQ 
// Add this point's contribution to our v 



curVTanE ] += controlsE i IE j ].getX() 
curVTanE 1 ] += controlsE i IE j LgetYQ 
curVTanE 2 ] += controlsE i IE j ].getZ() * bu.dbv 



bu.bv; 
bu.bv; 
■tangent. 

* dbu.bv; 

* dbu.bv; 

* dbu.bv; 
■tangent. 

* bu.dbv 

* bu.dbv 



} 

} 

// Now get our normal as the cross-product of the u and v tangents. 
curNormE ] = curUTanE 1 ] * curVTanE 2 ] - curUTanE 2 ] * curVTanE 1 ] 
curNormE 1 ] = curUTanE 2 ] * curVTanE ] - curUTanE ] * curVTanE 2 ] 
curNormE 2 ] = curUTanE ] * curVTanE 1 ] - curUTanE 1 ] * curVTanE ] 
// Normalize our normal (ouch!) 
float rinv = l.Of / sqrt( curNormE ] * curNormE ] ■^ curNormE 1 ] * curNormE 1 ] + 
* curNormE 2 ] ); 
*= rInv; 
*= rInv; 



curNormE 2 ] 
curNormE ] 
curNormE 1 ] 
curNormE 2 ] 



*= rInv; 



Continued on page 52. 
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} 



// Store these. 

memcpyC verts + ( stepU + ( stepV * numSteps ) ) * 3, curPt, 3 * sizeof (float) ); 
memcpyC norms + ( stepU + ( stepV * numSteps ) ) * 3, curNorm, 3 * sizeof (float) 

} 

} 

// We render each strip of the surface out as a triangle strip, 
for ( int StepV = 0; stepV < numSteps - 1; stepV++ ) 
{ 

int yO = StepV; 
int yl = StepV + 1; 
::glBegin( GL.TRIANGLE.STRIP ); 
for ( int StepU = 0; stepU < numSteps; stepU++ ) 
{ 

int xO = StepU; 

glNormal3fv( norms + ( xO + ( yO * numSteps ) ) * 3 ) 
glVertex3fv( verts + ( xO + ( yO * numSteps ) ) * 3 ) 
glNormal3fv( norms + ( xO + ( yl * numSteps ) ) * 3 ) 
glVertex3fv( verts + ( xO + ( yl * numSteps ) ) * 3 ) 

} 

::glEnd(); 

} 

// Clean up after ourselves, 
delete [] verts; 
delete [] norms; 




LISTING 4 . ( Continued from page 50.) 



vector of four associated basis functions, 
and renders the curve in 100 steps. 

To generate each point, it calculates 
Equation 2 for the input — it adds up 
the sum of each point times that point's 
basis function. For our cubic curve, this 
is certainly not the most optimized way 
to calculate the curve. However, because 
it's only 100 points, it's not noticeable 
andthedemo still runs quite fast. 



Surfaces: The Bezier Patch 

It might seem more consistent to 
cover not only Bezier patches but 
al so H erm i te patch es, as wel I . Th e rea- 
son we're skipping straight to Bezier 



FIGURE 4. A bicubic Bezier patch. 
The green grid connects the control 
points. 




patches is that we're trying to cover the 
curves and curved surfaces in the most 
intuitive order possible. Whereas it 
makes sense to cover Hermite curves 
and then Bezier curves, Hermite patches 
are somewhat more difficult to learn 
than Bezier patches. 

Si nee a Bezier curve was a function of 
one variable, f(u), it's logical that a sur- 
face would be a function of two vari- 
ables, f(u,v). Following that logic, sincea 
Bezier curve had a one-dimensional 
array of control points, it makes sense 
that a patch would have a two-dimen- 
sional array of control points. We'll now 
discuss bicubic Bezier patches. The 
phrase "bicubic" simply means that the 
surface is a cubic function in two vari- 
ables— it iscubic along u and also 
along V. Then, since our cubic Bezier 
curve had a 1x4 array of control points, 
our bicubic Bezier patch has a 4x4 array 
of control points. Figure 4 shows an 
example of a surface. 

Now, with that, we need to take our 
equation for evaluating a Bezier curve at 
someu and extend it to allow us to eval- 
uate our patch at some (u,v). The exten- 
sion isfairly straightforward. Wejust 
evaluatethe influence of each of the 16 
control points, yielding: 

f f RjBi=(u)Bf(v) Eq.3 

i=0 j=0 

We can see by inspection that our 



properties from the Bezier curve extend 
to the patches. Why? Forthefollowing 
reasons. 

1. The patch interpolates Pqq, Pq3, P3Q, 
and P33 asendpoints. 

2. Control points have local control, 
that is, moving a point over the center 
of the patch will most strongly affect 
the surface near that point. 

3. The patch remains within the con- 
vex hull of its control points. 



Implementing Bezier Patches 

Rendering a Bezier patch is more 
complicated than rendering a 
Bezier curve, even when doing it in the 
simplest possible way. With a Bezier 
curve, we could just evaluate a number 
of points and render a line strip. With a 
patch, we need to evaluate strips of 
points and render triangle strips. Also, 
with a patch we have to worry about 
lighting. After all, an unlit patch will just 
look I ike an oddly-shaped splotch of red 
on the screen. To see the contours, we 
need lighting. For our naive implemen- 
tation, that means we'll need to light 
each vertex. To light a vertex, we need 
its normal. So, for every (u,v) pair, we 
need to solve for the point on the sur- 
face, and then solve for its normal. 

Equation 3 tells us how to find the 
point on the surface, but how do we 
fi n d th e n rm al ? W el I , we kn o w we can 
take the derivative of the surface with 
respect to either u orv, which would 
yield the tangent vectors to the surface 
in the direction of either u orv, respec- 
tively. If we find both of those tan gents, 
we know that they both lie in the plane 
tangent to the surface. Then, taking 
their cross product will yield a mutually 
perpen d i cu I ar vector, th e su rface nor- 
mal. Finally, we'll have to normalize it 
since it most likely won't be unit length. 

So, how do we find df(u,v)/du and 
df(u,v)/dv? As it turns out, we can just 
take th e deri vat i ves of th e basi s f u n c- 
tions. That is, 

df(u) _ 
du 

d(£tpijBi^(u)Bf(v)) 

1=0 j=0 

du 

dBi^(u)^3, . 
i=o i=o Eq. 4 
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The same holds for the derivative 
with respect to v. Therefore, before 
ren deri n g, we cal cu I ate th e deri vati ves 
of the basis functions and store them. 
We use Equation 4 and its v analogue 
to find the tangents, and then proceed 
to find the surface normal. The code 
for the loop is shown in Listing 4. 

Now, while the curves didn't slow 
down from our naive implementa- 
tions, this patch demo shows quite 
painfully why optimization is very 
necessary. It runs at a steady 30 or so 
frames per second (again, on my 
Voodoo2), but that's just one patch. If 
you tried to base a terrain system on 
this implementation, it would be 
painfully slow. After all, consider the 
work we're doing. By default, thetes- 
sellator breaks the surface into 100 
points. At each point, we're evaluating 
32 cubic functions and 32 quadratic 
functions, then doing a vector cross- 
product and a vector normalization 
(ouch!). Then, for each point, we're 
asking OpenGL to light it, which is 
not cheap either. Plus, we're not 
caching any of this between frames, 
and we're actually allocating and then 
deallocating the space every frame. So 
we're doing a lot of work, much of it 
entirely unnecessary. 

Nonetheless, it works. We're render- 
ing a lit Bezier patch, and even if it is 
a bit sluggish, it looks pretty good. 
Now, if only we could do something 
with it... 
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Moving from Theory to Application 

Th ere are certai n I y a n u m ber of 
loose ends. We've covered Bezier 
and Hermite curves and Bezier patch- 
es, but the implementations so far are 
entirely unoptimized and the patch 
demo is rather sluggish even for what 
little it is supposed to do. 

Furthermore, we haven't seen an 
example of using these things in a real 
application. The demo code is just 
that — a demo of a curve or surface 
floating in black space. There is still a 



fair amount of material to cover 
before we can turn these into some- 
thing real. 

Next month, I'll cover some opti- 
mization techniques for Bezier curves 
and surfaces. We'll also see how to 
form other surfaces and objects by 
joining Bezier patches together, and 
look at some of the properties of such 
objects, as wel I as some of the prob- 
lems that can arise from the new tech- 
niques. Finally, having covered all of 
this, I'll finish off the article with afar 
more interesting demo. ■ 
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POSTMORTEM 




D eamU k 
I e ac i e 

Trespasser 



Btf Ricftarcl tUtfckoff 




ne seldom hears the true story of what happened at the 



place where the world changed. How it began. W hat 



were the reasons? W hat were the costs? 



—John Parker Hammond 



This quote fronn Trespasser's opening movie 



serves just as well to open the real story of a ganne 



development team's struggle to createa breakthrough dinosaur game as 
it does to open the fictional story of Hammond's struggle to develop a 
biotechnological breakthrough and clone dinosaurs. 




An Ambitious Project 



The parallels between the Trespasser project and Hammond's 
cloning project were numerous: ambitious beginnings, years 
of arduous labor, and an eventual tragic ending. Hammond's 
diary, as related in the game itself, dwell son the past and never 
attempts to explain Hammond's future direction now that he has 
failed so grandly. This postmortem is intended to be much more 
forward looking. 

Trespasser was begun by two former employees of Looking Glass 
Technologies, SeamusBlackley and Austin Grossman. By thetime 
thegamewas rolling, two more ex-Looking Glass employees would 



Richard W yckoff was a designer on Trespasser who worked previously at Looking Glass Technologies in 
small roles on projects like Flight Unlimited and Terra Nova. He's currently applying what he learned from 
Trespasser to an unannounced project at Knowledge Adventure Contact him at rwyckoff@loonygames.com. 
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join theteam, and our common background was instrumen- 
tal in setting the direction for the project. 



The Concept 

The pi e-in-t he-sky concept for Trespasser was an outdoor 
engine with no levels, a complete rigid-body physics 
simulation, and behavioral I y-simu I ated and physically mod- 
eled dinosaurs. The underlying design goal was to achieve a 
realistic feel through consistent looks and behaviors. Having 
an abandoned island setting was a useful way to exclude 
anything which did not seem possibleto simulate, such as 
flexible sol ids I ike cloth and rope, wheeled vehicles, and the 
effects of burning, cutting, and digging. 

The game would play from a first-person perspective, and 
you would experience theenvironment through a virtual 
body to avoid the "floating gun" feeling prevalent in the 
WoLFENSTEiN breed of first-person games. Combat would be 
less important than in a shooter, and dinosaurs would be 
much more dangerous than the enemies in traditional first- 
person shooters. The point of the game would be exploration 
and puzzle solving, and when combat happened, it would 
more often i n vol ve f ri ghten i ng opponents away by i nfl i cti ng 
pain than themercilessslaughter of every moving creature. 

Theoriginal plan for Trespasser certainly seemed likea 
good one. It was very ambitious, but theteam made trade- 
offs on implementation and execution time from the very 
beginning. For instance, theteam wouldn't attempt to do 
multiple or moving light sources or Qu AKE-sty I e shadow gen- 
eration in order to accommodate arbitrary numbers of mov- 
ing objects and long, wide-open views. Unfortunately, there 
is a difference between having a plan and successfully exe- 
cuting it, and the product that we eventually shipped was as 
disappointing to us as it was to the great majority of game 
players and game critics. 

Some have dismissed Trespasser altogether because it was 
such a visible failure. Respected industry columnists and edi- 
tors use it as a reason why physics is bad, or make it the butt 
of their jokes ("at least it wasn't as bad as Trespasser!"). 
However, from a project perspectivethere were a number of 
successes. Before we get into the problems which ended up 
si n ki n g th e sh i p, I et's I ook at th ese successes. 



What Went Right 

IUSE OF LICENSE. M aklng a new story with someone else's 
• licensed property is often creatively stifling for design- 
ers and ultimately disappointing for fans of theoriginal 
work. Thejurassic Park license could have been an especially 
limiting one, representing some of director Spielberg's and 
novelist Crichton's weakest work. However, Trespasser's 
Hammond diary actually contains lots of interesting tidbits 
about the early days of characters like Henry Wu (the scien- 
tist from the beginning of the first movie) and Dennis Nedry 
(Wayne Knight's character who basically caused the first dis- 
aster), which made the game world a richer environment. 
The player can also check out locations on the island which 
imply backstory which isn't explicitly told, like Henry Wu's 
house with its 1980s executive bachelor stylings, Nedry's 




office with its poster for the fictional computer game series 
"Swords of Kandar," and Hammond's lavish mansion. The 
settings and the diary itself serve to reveal much of 
Hammond's motivation and personal reactions to the build- 
ing of Jurassic Park, creating more of a character than exists 
in either the books or the movies. (Crichton killed 
Hammond off in thefirst book, anyway.) 

The overall plot of our game is as simplistic as most others 
(the character must find a way to escape a death trap), but 
the details revealed about thejurassic Park world extend it in 
a way which isfaithful to theoriginals. Although it isquite 
likely that the next jurassic Park movie to be released will 
make Trespasser non-canon, for now it stands as the only 
real extension of the series published. If there are such 
things asjurassic Park fanatics and they were able to look 
past the game play flaws, they hopefully enjoyed our devel- 
opment of the world. 

2 Art AND MUSIC. On an individual basis, the models cre- 
# ated for Trespasser rank with the best-looking work 
done for computer games. We limited the largest texture size 
to 256x256 pixels, and at model import time textures were 
converted to 8-bit paletted images. But artists worked with 
their models using 24-bit art in 3D Studio Max, applying the 
textures using any mapping methods that M ax supported. 
We had the standard limits on visible polygons, so most 
models were made with as few as possible: dinosaurs ranged 
from 300 to 500 polygons and trees from 50 to 120, for 
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example. Butthisstill gave our artists 
more complexity than was standard at 
the time. 

M any of Trespasser's artists had never 
worked on games or done 3D modeling 
before, and some had never even used 
computers at al I . Th i s was a fai riy del i b- 
erate decision, in an attempt to achieve 
a much higher standard of art than we 
were used to seeing on previous prod- 
ucts. The number and resolution of tex- 
tures we were able to support called for 
pai n t i n g ski 1 1 s far beyo n d th e average 
game-trained artist. 

The music is one of Trespasser's best 
accomplishments. Originally, we were 
slated to use John Williams's score, but 
the cost proved to be execessi ve. 
Fortunately, our sound effects 
company, SounDelux, put us 
in touch with oneof their sta- 
ble of composers who special- 
ized in "imitation" music. 
With very little prompting, he 
recorded about 30 minutes of 
music for us which in some 
parts far exceeds the rather 
f orgettabi e work W i 1 1 i ams 
himself did for the Jurassic 
Park movies. 

Some reviews still accused 
us of having spotty or inap- 
propriate music, but this was 
more an implementation 
problem than a problem with 
the music itself. The music was 
recorded as a couple dozen short sec- 
tions which were scattered through the 
world on location -based triggers. Much 
I ike the voice-overs, more attention 
could have been paid to their placement 
so that they only played at appropriate 
and regular intervals. Even more desir- 
able would have been a system with the 
ability to play tension or combat music 
I oops an d fade th em i n an d out of th e 
special -event songs to make it seem 
more I ike a continuous musical score. 

S Innovative systems. Our artists 
# were able to paint textures with 
near-total disregard for common memo- 
ry-conservation practices, thanks to the 
textu re each i n g system wh i ch on e of 
the last programmers to be hired created 
fairly I ate in the project. 

Textures for our game were M I P- 
mapped by our helper application, 
GUI App, as part of the process of bui Id- 
ing level data (curved bump maps were 
also created at this time). A level could 
have a nearly unlimited amount of tex- 



tures, and once M I P-maps were created, 
all textures and their M IP-maps were 
saved into a single swap file. GUIApp 
automatically organized the swap files 
into pages based on texture size, with 
th e I owest cou pi e of M I P I evel s f or al I 
textures on a set of pages which were 
always committed. 

Asthe player moved through the 
level and objects came into view, the 
appropriate pages from the swap file 
were accessed. In any circumstances 
where an appropriate textu re hadn't 
been loaded in yet, the always-commit- 
ted M I P-maps could be used until the 
higher-resolution texture had been 
loaded. In theory, thiscould result in a 
frame or two where an object was tex- 




tured at a lower resolution than desired, 
but in practice it rarely happened, even 
on the most textu re-in tensive levels. 

Another major system for Trespasser 
was its audio system, which we 
described as "real time Foley" because 
of its ability to generate collision and 
scraping effects between differing 
sound materials in real time. Although 
the system could have used more sound 
material data, even with what it had it 
resulted in some wonderfully immer- 
sive sound effects which most other 
games do not duplicate— things like 
scraping a board down a concrete sur- 
face or hitting an oil barrel with a metal 
bat sound almost perfect. The system 
doesn't Just play two stock effects but 
actually chooses from several samples 
and sets volumes based on the strength 
of the underlying physics collision, 
with very natural-sounding results. 

Finally, our image caching system, 
which rendered groups of distant 
objects into single 2D bitmaps to speed 



rendering, while responsible for the 
most disturbing visual anomalies in the 
game, was also by its own right an 
amazing piece of work. I mage caching 
allowed scenes with tens of thousands 
of polygons to be rendered in near-real 
time, and it isthefirst technology 
which has all owed outdoor scenes to 
have a reason able fraction of the com- 
plexity of the real outdoors. 

4 Outdoor level design. When we 
# created our terrain geometry, 
we were deliberately trying to avoid the 
"marbles in rubber" look of a lot of bad 
fractal I y-generated outdoors. To this 
end, we decided that we needed to base 
our island on real-world terrain rather 
than build it from scratch. Luckily, we 
had a real -world model to go 
from: Costa Rica's Cocos 
Island, thesame island which 
C rich ton used as his inspira- 
tion for Site B. Unfortunately, 
no relief maps of sufficient 
detail existed for the island, so 
we ended up having our lead 
artist sculpt a large model of 
the entire island, had it laser 
scanned, and did all ourfinal 
work on it in 3D Studio Max. 

M odel i n g was on I y th e fi rst 
step to creating a level. After 
most of th e terrai n was estab- 
lished, it took significant time 
to populate the levels with 
objects. There were 10-15,000 
trees, shrubs and rocks in most levels, 
and a few thousand man-made objects 
as well. Every object could be placed 
individually, but for time-saving rea- 
sons we generally used groups of 
objects for areas off the gamepath and 
only spent a lot of time hand-placing 
items in places we knew the player 
would go. The rolling terrain and a ran- 
dom-delete tool we often ran for opti- 
mization generally kept the repetition 
from seeming obvious. 

In theend, although our levelsdid- 
n't quite fulfill our personal expecta- 
tions, they usually look more like real 
environments than previous games. 
Starting from a real map seemed to be 
the most useful tactic for this, and 
lookingfor a real -world starting point 
for vegetation placement is the next 
obvious step for outdoor games. 

5 Realistic physics in a first-person 
# PERSPECTIVE. The first discovery 
we made as our physics simulation was 
slowly implemented was that it was an 
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engrossing toy. When we finally got 
support for compound object physics 
(so that a bench could consist of a top 
and two legs instead of a single block, 
for instance), it was possible to spend 
an hour just dropping the bench onto 
things to see how it would catch on 
edges and flip and slide around. Toys 
do not make games, however, and try- 
ing to establish game play that would 
work with our simulation was our 
major challenge. 

Due to the vagaries of our particular 
physics simulation and interface, we 
eventually arrived on game play that 
primarily involved knocking things 
over rather than stacking things up. 
Knocking over will probably be the first 
application of realistic physics to see 
widespread use, as it will work even 
with a less-than perfect physics model 
(such as Trespasser's). It is also a behav- 
ior which easily shows off the differ- 
ence between realistic physics and 
what we usual ly referred to as "fake" 
physics — compare pushing a box off a 
ledge or hill in any game which actual- 
ly lets you move boxes to the same 
action in Trespasser. 

Since our game play was supposed to 
revolve around the physics, however, 
we needed to apply that knocking-over 
behavior in slightly more sophisticated 
ways than just using it as eye candy. 
The best uses that we found in the 
small amount of timewehad involved 
kn ocki n g stacks of boxes down to fi 1 1 
holes, or unbalancing something rest- 
ing on a high ledge in order to get it or 
use it as a step. It also quickly became 
apparent that building even a seeming- 
ly simple knocking-down puzzle 
required a much more highly refined 
sense of physical laws than many of us 
had. 



What Went Wrong 

it might seem as though Trespasser 
deserves more entries in its "what went 
wrong" section than the usual project 
postmortem. However, Trespasser's 
failingsareactually few in number. 
Unfortunately, thefailings that wedid 
have were serious enough to more than 
outweigh our successes. 

1 Software-oriented renderer. 
# Trespasser was begun before the 
original Voodoo started the wave of 3D 
hardware popularity. The Trespasser 




engineers set about to create an engine 
in the old-school manner: they picked 
some previously-unseen rendering 
technologies and implemented them, 
ignoring any issues of compatibility 
with hardware cards. Our engine's two 
most incompatiblefeatures were its 
bump mapping (which used a true geo- 
metrical algorithm that could take sur- 
face curvature into account) and its 
i mage each i n g. I mage each i n g was 
intended to allow real-time rendering 
of huge numbers of meshes, but it was 
also the system almost solely responsi- 
ble for the graphical anomalies of pop- 
ping, snapping trees in the game. The 
other primary visual artifact of the 
game was the frequent sorting errors, 
but this was a result of poorly-con- 
structed levels which continually 
handed our depth-sort algorithm more 
polygonsthan its limit, and not a 
direct result of image caching itself. 

The image cache system worked by 
rendering distant objects into 2D 
bitmaps on the fly, and then updating 
them when the angle or distance 
changed enough so that the 2D repre- 
sentation was no longer sufficiently 
accurate. This may sound familiar to 
those who remember M icrosoft's 
Talisman architecture, and there was a 
hope at onetime that our game would 
be a "killer app" for Talisman accelera- 
tors, but resistance from key figures in 
the industry and 3dfx's sudden popu- 
larity pretty much put an end to 
Talisman. 

Trespasser ended up slipping by 
more than a year, as did many games 
of its time. Our hardware programmer 
put in a valiant effort in the last half 
year of the project, and managed to get 
much more use out of 3D hardware 
than we initially thought possible. We 
ended up with a fairly unique mixed- 
mode renderer which drew any bump- 
mapped objects in software and the 
rest of the scene with hardware. 



U n f o rt u n at el y , t h e I arge n u m ber of 
bump-mapped objects present in our 
game, such as all the dinosaurs and 
nearly every crate, meant that the fill 
rate advantages of accelerators were 
often negated. 

In addition to being a costly soft- 
ware-only rendering method, our 
bump mapping was never very evident: 
we could have used multiple, moving 
light sources and had the art staff make 
better use of bump maps in their 
objects. Many of the bump maps were 
created by simply converting the origi- 
nal texture to grayscale, an artist's hack 
that works for rendered images and 
animations but not in real-time 3D. 
I mage caching was an even bigger 
problem than bump mapping, because 
although it was the key technology 
that we were using to try to improve 
scene complexity, the game's visual 
quality was also the source of most 
people's complaints. It seems clear in 
retrospect that we should have made a 
tradeoff somewherealong the line and 
ei th er d ropped th e ph ysi cs tech n o I ogy 
and physics game play in favor of the 
rendering technology, or more likely 
dropped the rendering technology and 
the ability to do complex scenes in 
favor of the physics technology. 

2 Game design problems. The 
# biggest indication that 
Trespasser had game design problems 
was the fact that it never had a proper 
design specification. For a longtime, 
the only documents which described 
the game play were a prose-style walk- 
through of what the main character 
would do as she went through the 
game, and a short design proposal list- 
ing the keys which would be used and 
some rough ideas of what game play 
might actually be. 

Our experiences on Trespasser made 
it clear that it is worse not to have a 
design specification at all than to have 
one which becomes out of date and is 
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Level design in Max was tolerable, not 
enjoyable, for tlie Trespasser team. 



frequently rewritten. Trespasser started 
and finished weak in the game design, 
and this affected every other part of 
the project. 

When it became clear that the tech- 
nology was not going to exist to sup- 
port the initial high-concept design, it 
would have been best to throw out all 
our existing notions and reinvent the 
game. Unfortunately, our license made 
it all but impossibleto throw out the 
original Trespasser concepts. The only 
major deviations from the original idea 
were the change from constructive, 
stacking-based physics puzzles to 



destructive, knocking-over puzzles, and 
an attempt to make combat more 
prevalent in order to shore up the 
weakness of the destructive physics 
puzzles. Since no part of the Trespasser 
code was written to be good at doing 
first-person shooter game play, this 
attempt to make shooting a more 
important feature only ended up 
flaunting some of the weaker points in 
thegame, like the lack of an inventory 
system and the slow frame rate. 

STOOLS PROBLEMS. TRESPASSER WaS 
# built entirely in 3D Studio Max. 
There was no level editor, only the 
generically-titled GUIApp, which was 
the game with a debugging shell — not 
really a tool at all. Our level creation 
procedure consisted of arranging 
20-25,000 meshes in Max, using 
dummy meshes to represent game play 
objects I ike triggers, and typing trigger 
code into these objects' "object proper- 
ties" buffer. 

There were two unexpected and 
incredibly severe drawbacks that we 
discovered only after it was far too late 
to change our method of building the 
game world. Thefirst problem was that 
M ax is basically unfit to work with 



more than about 5,000 objects at a 
time. Trespasser levels averaged 40M B 
in size, and could take a couple min- 
utes to load on the systems our design- 
ers used (Pentium 11-266 with 256MB 
RAM). When all objects in a level were 
visible, it could take from 30 to 60 sec- 
onds to respond after clicking on an 
object to select it, making fast work dif- 
ficult (to say the least). 

The second problem with the Max 
method was our use of the object prop- 
erties text buffer. The buffer seems to 
be one of those features which no one 
ever used before, because we discov- 
ered that if more than 512 characters 
were typed into an object's properties 
buffer. Max could become unstable. If 
Max didn't crash outright and a file 
was saved with one of these bad 
objects, it would become unloadable. 
Trespasser's technical artist wrote 
many design tools in MaxScript and 
also coded warning scripts to guard 
against problems such as properties 
buffer overflows, but these solutions 
only made designing in Max tolerable 
— not enjoyable. 

There was an additional wrinkleto 
the process of using M ax to create lev- 



els, and this was the export step. A Max 
plug-in converted data into the game 
format, but our particular exporter 
caused a lot of problems. It was devel- 
oped by a programmer who worked 
from home, an hour away from the 
office, and used a separate code base 
with unique classes and a different ver- 
sion of the compiler. This was also his 
first project in 3D, and it became the 
second-most delayed part of the pro- 
ject after physics. Until the last year of 
the game, there were significant bugs 
in the exporter which required time 
consuming work-arounds. Important 
functionality, such as the ability to 
export object properties, also was not 
delivered until very late in develop- 
ment, which prevented designers from 
implementing game play. In the end, 
the exporter was assigned to another 
programmer and rapidly brought up to 
usability, but it had already delayed 
level building significantly. 

4AI PROBLEMS. The largest prob- 
# I em with theAl system was 
that its progress was blocked by a lack 
of dinosaurs with which to test it. The 
first timea dinosaur made the transi- 
tion from a separate test application 



into the game was in early 1998, with 
significant missing functionality which 
prevented the completion of visually- 
important Al behaviors, like howling 
and glaring. The first quadruped went 
in around the early summer of 1998, 
about four months from the then- 
intended ship date (as it turned out we 
slipped by about another month). 

The dinosaur Al was a state- based 
system, based on the creatures' emo- 
tions. It became apparent once 
dinosaurs were working well enough to 
put into levels that the differences 
between the activity states were not 
discrete enough. Dinosaurs were gov- 
erned by a set of emotions which theo- 
retically would prompt them to pick 
appropriate responses at any time. 
However, in practice they would end 
up oscillating rapidly between many 
activities, sometimes even literally 
standing still and twitching as they 
tried to decide what to do. M aking a 
usable dinosaur required disabling all 
but one or two of their activities. This 
allowed aggressive dinosaurs to really 
be aggressive, but it also meant that 
most dinosaurs were as single-minded 
as the traditional videogame monsters 



we were trying to one-up. 

TheAl system suffered from the lack 
of a clear game design. There are two 
scenes in thejurassic Park movies 
which demonstrate quintessential 
dinosaur game play: the scene in 
Jurassic Park where the kids hide from 
raptors in a kitchen, and the scene in 
Lost W Grid wherejeff Goldblum deals 
with several cautious raptors in the 
ruins of the town. Both of these scenes 
rely on dinosaurs which can befooled 
by ducking behind objects and which 
can home in on or be distracted by 
localized noises. Neither of these two 
fundamental abilities is actually pre- 
sent in theTRESPASSERdinosaur Al. 
Instead, the dinosaurs have a simpler 
and more industry-standard detection 
radius which doubles as sight and hear- 
ing and is not blocked by objects in 
any way. Without a design specifica- 
tion calling for these kind of behaviors, 
though, theAl development went in 
directions which ended up being large- 
ly unsuitable for game play. This prob- 
lem wasn't even discovered until a few 
months before we shipped, when there 
was only time to work around it rather 
than completely rework it. 
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5 Physics problems. The box 
# model was Trespasser's most 
significant physics innovation: it was 
intended to be a complete simulation 
of any arbitrarily-sized box interacting 
with a number of other boxes. The 
approach used in Trespasser was what 
is known as the "penalty force" 
method. In incredibly simple terms, 
when boxes collide, they are all owed to 
intersect with each other (mathemati- 
cally), and then they push each other 
apart until they are no longer intersect- 
ing. The penalty force model is general- 
ly believed to bean unworkable one by 
the few other people in the industry 
attempti ng real-ti me sol ids models, but 
our physics programmer believed he 
could make it work. 

There were several notable flaws with 
Trespasser's solids model as shipped: it 
ended up only working well when used 
with roughly cube-shaped boxes with 
dimensions between 0.5 and 1 meter 
on aside, it did not model friction well, 
it was extremely slow, and it was not 
free of interpenetration even within the 
size constraints. 

We were aware that physics would be 
slow, and that ten boxes at once would 
represent the practical upper limit, but 
we had not expected that so much of 
that physics overhead would be eaten 
up by the dinosaur body physics, which 
used five boxes in the worst cases: head, 
body, tail, and two feet. Although the 
d i n osau r ph ysi cs boxes executed faster 
because they did not interact with each 
other, it turned out that in common 
cases ( I i ke a seen e d i sp I ay i n g t wo rap- 
tors and the player holding a gun), the 
physics budget was completely con- 
sumed an d th ere were n o were n o 
processor cycles left to handle knocking 
over a stack of boxes. 

Physics speed was an issue, but other 
problems were more severe. The game 
design depended on boxes of sizes 
other than small cubes, and we ended 
up including many objects outside that 
safe range. Unfortunately, all objects 
outside the safe range, even large cubes, 
were more prone to reveal the most 
egregious problem with the physics sys- 
tem: interpenetration. At best, these 
interpenetration bugs completely blow 
the consistency of simulation we tried 
to set up, and at worst they make the 
game unplayable. If it was not clear 
before shipping Trespasser, it is clear 
now: no amount of interpenetration is 



acceptable, and preventing it absolutely 
should be the number one concern of 
any physics coder. 

Trespasser's dinosaurs and the arm 
itself were inverse-kinematic (IK) sys- 
tems control led by physical models. 
Originally, thedinosaurs were sup- 
posed to be full physically-modeled 
bipeds whose physics actually knew 
how to use legs to stand, walk, run, and 
jump. They ended up with more stan- 
dard game movement physics and an 
IK animation system very similar to 
Looking Glass's Terra Nova. Just like 
in Terra Nova, the dinosaur legs fre- 
quently stretched, bent, and popped as 
the IK system struggled to handle the 
physical ly i mpossi ble movements that 
thesimplified physics generated. 

This movement problem was a case 
of lacking realistic boundary condi- 
tions. The joints of the arm never had 
realistic limitations put on their rota- 
tion or even limitations on the dis- 
tances between joints. A system written 
by a different programmer sat on top of 
the underlying arm system and contin- 
ually tried to make sure it had not 
moved into an impossible position, but 
as a separate system it could only be 
partially successful at best. The arm as 
shipped would often go almost out of 
control for a few frames, stretching or 
spinning in impossible ways. During 
this time thefragilefeeling of connec- 
tion between the player and their char- 
acter wou I d be sh attered . 

The arm suffered not only from its 
unbounded model but also from bad 
design choices. Its creator intended it to 
be wholly context-insensitive. The fact 
that guns, unlike other objects, get held 
fairly steadily and away from the body 
was only a result of some key members 
of the test staff adding their voices to 
the cries which had been coming from 
within theteam to fix shooting so that 
it was easy to hit a desired target. It 
should have been obvious from the 
mere fact that a 2D i nterface was bei ng 
used to move in 3D space that an even 
larger amount of context sensitivity was 
needed. If a truly successful virtual arm 
is ever to be implemented, simple 
mouse movements will have to be 
translated into complicated arm move- 
ments based on what is in or near the 
hand, or it will be as impossible to use 
as Trespasser's arm. That there was a 
conscious decision to avoid context 
sensitivity in our project is indicativeof 



the larger problems with physics in our 
proj ect . Th e ph ysi cs code was I argel y 
written in a vacuum and tested in sepa- 
rate applications and non-representa- 
tional levels, and not enough attempts 
were made to analyze it from a player's 
perspective and design it to support 
game play in every way. 

Lessons Learned 

How did Trespasser end up ship- 
ping with the number of prob- 
lems that it had? Trespasser was a pro- 
ject with management problems at all 
levels. It suffered from being an innova- 
tive, technologically ambitious project 
produced by a team with little previous 
management experience at a company 
which had not yet gained institutional 
experience from publishing significant, 
less-ambitious projects. 

It has been nearly half a year since 
Trespasser shipped. In that time it has 
gonefrom a gigantic Christmas letdown 
to an occasionally-referenced joke. The 
team has mostly disintegrated. Some 
quit, some were let go, and those re- 
maining were distributed across several 
different projects. Theengineiseffec- 
tively dead, and the new DreamWorks 
motto is "licensed technology" — prob- 
ably a good idea for the company but 
pretty d i sh earten i n g f o r t h e en gi n eers 
who created last year's most innovative, 
if not quite best, engine. A group of 
Internet fans proclaimed themselves the 
Trespasser Hacking Society and have 
taken up the lunatic task of trying to fig- 
ure out how to bui Id a mod for an 
engine which was barely usable with its 
in-house tools. 

Th at Trespasser sh i pped at al I i s a tes- 
tament to the strength of the individual 
members of its team. In looking back at 
my own experience, I find that I learned 
a lot about game development, and I'm 
already putting that knowledge to 
work. Although the game does not ful- 
fill the many high hopes I had for it (or 
even my base expectations), I am happy 
with the work I put into it. I also hope 
that every other person who con- 
tributed to the massive effort isequally 
proud of their work, and that sometime 
in the future we all have a chance to 
make a major project that succeeds 
where Trespasser failed. ■ 

Editor's Note: A longer version of this 
articleis availableon Gamasutra.com. 
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So You Want to Do 
Movies? Good Riddance! 



othing annoys me more than game devel- 
opers who long to work in a different 
medium. From the artist who dreams of 
working at I LM to the musician who's 





waitingforthat big recording deal to 
come through, these developers don't 
real i ze th e true poten ti al of games as an 
artistic medium. Even some of the high- 
est-profile game industry personalities 
seem more interested in using 
games as a steppi ng stone i nto 
Hollywood than they do in 
maki n g games a fi rst-cl ass art 
form that can stand along- 
side movies, music, books, 
painting, and theother 
accepted media. 

Why do I get so aggravat- 
ed by these grass-is-greener 
developers? Because they 
don't see games as a creative 
medium worthy of respect. 
Yes, one needs a bit of i magi- 
nation and optimism to see 
how games wi 1 1 someday be as 
mature as literature or painting. 
However, peoplealso needed imagi- 
nation back in 1900 to foresee how film 
would be the mature art form it istoday. 
I'd bet the film makers who lifted movies 
up from The Great Train Robbery to 
today's standards didn't do it because 
they all secretly wanted to be play- 
wrights, painters, and musicians. They 
did it because they could seethe poten- 
tial of motion pictures for creative and 
artistic expression — and wide sociolog- 
ical impact. 

Developers often complain about the 
I imitations of games as an expressive 
medium. Wecan't have graphics as 
detailed as Pixar's animations, our audio 
is lame compared to what you can get 



out of a CD on your stereo, and so on. 
Yes, there are loads of technical and aes- 
thetic I imitations to games. But you 
don't hear painters complaining that oil 
paints aren't 




water solu- 
ble, or that water 

colors don't create texture on the can- 
vas. Artists who work in mature media 
— I ike the different gen res of paint, 
film, and writing — revel in thediffer- 
ences between their media. They don't 
complain about them! Constraints and 
limitations are part of a medium's 
charm and character — not to mention 
its identity. If you want the characteris- 
tics of oil paints, go useoil paints. If you 
want a new medium that has the best 
characteristics of both oil and water col- 
ors, then go invent it — but don't be 



Chris Hecker hopes somebody does the game equivalent of Birth of a Nation soon, so 
somebody else can do the game equivalent of Casablanca, his favorite movie. Hecan 
be reached at checker@d6.com. 



surprised if it doesn't quite work out. 

Enough about other media. What is 
th e defi n i n g ch aracteri sti c of games as 
an artistic medium? The answer is clear: 
interactivity. Wefinally have an art 
form where the work of art itself can 
respond to the viewer. Everyone in our 
industry pays lip service to interactivity, 
but this abi lity for each audience mem- 
ber to create his or her own intimately 
personal experience is the critical reason 
why games will impact society at large, 
not just testosterone-addled 16-year-old 
boys. Interactivity is a completely novel 
artistic opportunity, and it's clear 

from our crude attempts to 

harness it that we have a 
long way to go before our 
craft matures. But it will 
happen. 

In that poetically ironic 
sort of way, interactivity is 
the basis for all of our limi- 
tations as a medium as well. 
Fi I ms wi 1 1 always be more 
graphically detailed than 
games because they don't 
h ave to gen erate seen es i n 
real time. That'san inherent 
fact of interactivity. Yes, we 
can always work towards more 
realism and higher graphical 
standards — but we will never catch 
film on that front. Rather than sending 
our resumes to Digital Domain, we 
should recognize this limitation and 
appreciate that in return, we're gaining 
something film will never achieve— a 
truetwo-way dialog with the viewer. 

We have a responsibility to our 
nascent art to help it grow into a full- 
fledged medium. Someone among us, 
or someone who hasyettojoin the 
game industry, will develop our equiva- 
lent of Birth of a Nation and the world 
will never bethesameagain. Asa game 
developer, you can either help this 
medium reach maturity, or hinder this 
process by viewing it solely as a step- 
ping stone to other creative arenas. If 
you're not committed to the growth of 
games as an art form, then don't let the 
door hit you on your way out. ■ 
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